Lambda, SNS and SQS all support attaching a policy directly to the resource itself, so some other principal — an AWS service reacting to an event, or another AWS account — can invoke, publish to, or send to it without that principal needing an identity-based policy of its own. The three services use the same JSON shape for this, differing only in which action goes in the statement. Resource-Based Policy Generator builds that shared shape for whichever of the three you pick, with the one check that matters most for this kind of policy built in: whether a service-principal grant is actually scoped to your resource, or left open to any account’s matching resource.
You choose the service (Lambda, SNS, or SQS), enter the ARN of the resource the policy will attach to, and pick a principal: either an AWS service principal — s3.amazonaws.com triggering a Lambda function, events.amazonaws.com for an EventBridge rule, or any other service principal you type in — or a specific AWS account/role ARN for cross-account access. The action defaults to the one thing each service’s resource policy is almost always used for (lambda:InvokeFunction, sns:Publish, sqs:SendMessage), with room to override it if you need a different action.
The real logic in this tool is the scoping check. Granting a broad service principal like s3.amazonaws.com permission with no further restriction does not just allow your own S3 bucket to invoke your Lambda function — taken literally, it allows any S3 bucket in any AWS account to do so, because the principal is the S3 service as a whole, not a specific bucket. This is a documented, well-known pitfall with Lambda and SNS/SQS resource policies, sometimes called the confused-deputy problem. The tool offers two optional conditions to close it: a Source ARN field (rendered as an ArnLike condition on aws:SourceArn) that restricts the grant to one specific triggering resource, and a Source Account field (rendered as StringEquals on aws:SourceAccount) that restricts it to one specific account. After you build a statement, the tool inspects the resolved principal and condition block and shows a warning — computed from what you actually built, not a static disclaimer — whenever the principal is a service principal and neither scoping condition is present. Adding either condition, or switching to a specific account/role principal instead of a service principal, clears the warning because the underlying condition genuinely changes.
Once assembled, the statement is wrapped in a policy document and run through the same structural validator used across these tools: Version present, Statement non-empty, each statement carrying a recognized Effect, an Action, and a Resource or Principal. That, together with the scoping check, is the complete scope of what is verified — nothing here calls the AWS API, confirms the resource ARN you entered actually exists, or accounts for other statements already attached to the resource.
The output is a ready-to-attach resource policy JSON document with stat cards summarizing the statement, a clear warning when a service-principal grant is left unscoped, and Copy/Download actions — built entirely in your browser, with resource ARNs and account IDs never leaving the page.