A queue policy with Principal set to star grants the permission to everyone, including anonymous users, so it is safe only when strict conditions narrow it, such as a source ARN, source account or VPC endpoint. For most queues, name the exact accounts, roles or services instead.
What star means in SQS
The AWS SQS policy examples include one titled "Grant a permission to all users." It shows a statement with Principal set to star and the action ReceiveMessage, and the documentation describes the effect as granting permission to all users, anonymous users. Other examples show how to narrow that: a time window, a CIDR range, an allowlist and blocklist of address ranges. They exist because star with no condition is wide open.
AWS uses these examples to teach the policy language. That does not make them a pattern to copy into production.
Safer choices
| Need | Use instead |
|---|---|
| One other AWS account sends messages | Principal set to that account or a role in it, with only SendMessage |
| SNS delivers to the queue | The SNS service principal with an aws:SourceArn condition, see the SNS to SQS policy guide |
| Traffic must stay in your network | Allow only through your VPC endpoint, see the VPC endpoint guide |
| Several accounts share the queue | List each account explicitly, and give each only the actions it needs |
Know the limits of cross-account grants
The SQS documentation lists actions that cross-account permissions do not cover, such as CreateQueue, DeleteQueue, ListQueues, SetQueueAttributes, AddPermission and RemovePermission. That helps you reason about what another account can do through a queue policy, but do not use it as a reason to be loose with the actions that are covered. SendMessage and ReceiveMessage are the powerful ones: the first lets someone inject work into your system, the second lets them read your messages.
Steps to audit
- List all queues in each account and region.
- Read each access policy. Search for a Principal value of star, an AWS value of star, and a Service principal without a Condition.
- For each hit, ask what the intended caller is. If the answer is a service or an account, replace star with that.
- If star must stay, add a condition for a source ARN, a source account, a source VPC endpoint or a CIDR range, and keep the action list as short as possible.
- Send a test message from a principal that should not be allowed and confirm it fails.
- Add a check to your infrastructure as code pipeline so a new star policy is flagged before deployment.
Think about what is in the queue
Even a send-only grant is risky if the consumer trusts the message. An outsider who can send can try malformed payloads against your consumer code. The consumer is an endpoint, as explained in Your queue consumer is an unreviewed endpoint. A read grant is worse, because queues often carry customer identifiers, internal URLs and tokens.
Try it yourself
Click through it at your own pace, or open it full screen. Consider how a recurring check would catch a queue policy that someone widened during an incident.
Safeguard's policies and gates can flag risky configuration in pull requests, and the free scan is a quick start on your dependencies.
Quick check
Does a CIDR range condition make a star principal safe?
It narrows the callers to a network range, which can be reasonable for known networks. Public ranges or broad corporate ranges still allow many callers, so prefer named principals.
Can the SQS console show me risky policies?
You can read each queue's access policy there. For many queues, script the review or add checks to your infrastructure code.
Sources
Last reviewed: 19 October 2026.
