# Ensure SQS queue policies do not allow public access - Source: https://support.icompaas.com/support/solutions/articles/a_179329222608979-ensure-sqs-queue-policies-do-not-allow-public-access - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that no Amazon SQS queue has an access policy that makes it public. A queue is public when its policy has an Allow statement for any principal ("\*", {"AWS": "\*"} or {"CanonicalUser": "\*"}) without a condition that restricts who can use it. Queue policies should grant access only to the owning account or to explicitly trusted principals. **Rationale** Public access to an SQS queue can expose message data, allow anyone to send, receive or tamper with messages, and allow purge or delete operations that disrupt processing. It can also lead to unbounded message ingestion, causing cost spikes and overloading consumers. Applying least privilege to queue policies, by avoiding Principal: \* and granting access only to specific accounts, roles or services with restrictive conditions, protects the confidentiality, integrity and availability of the queue. **Impact** - Prevents unknown principals from sending, receiving or deleting messages - Protects message data and the applications that consume the queue - Principals or AWS services in other accounts that rely on the public statement will lose access until they are explicitly allowed **Default Value** A queue created without an access policy can be used only by principals in the owner account that have IAM permissions. The basic access policy offered by the SQS console grants access only to the queue owner. **Pre-Requisites** - IAM permissions: sqs:ListQueues, sqs:GetQueueAttributes and sqs:SetQueueAttributes - A list of the accounts, roles and AWS services that legitimately send to or receive from the queue **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon SQS console and select **Queues**. 3. Select a queue and open the **Access policy** tab. 4. Check for any statement that: - has "Effect": "Allow", - has "Principal": "\*", "Principal": {"AWS": "\*"} or "Principal": {"CanonicalUser": "\*"}, and - has no Condition that restricts access, for example by aws:SourceAccount, aws:SourceArn, aws:PrincipalAccount or aws:PrincipalOrgID. 5. Repeat for each queue in each region in use. 6. If such a statement exists, follow the implementation steps. **CLI:** List the queues in a region: aws sqs list-queues --region --query "QueueUrls" Show the access policy of a queue: aws sqs get-queue-attributes --region --queue-url --attribute-names Policy A queue fails if any Allow statement has a public principal (\*) and either no Condition, or a condition that does not use a restricting key such as aws:SourceAccount, aws:SourceArn, aws:SourceOwner, aws:PrincipalAccount, aws:PrincipalOrgID or aws:SourceVpce. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon SQS console and select **Queues**. 3. Select the queue and choose **Edit**. 4. In the **Access policy** section, for each public statement, either: - replace the "\*" principal with the specific account or role ARNs that need access, or - add a condition that limits access, for example "Condition": {"StringEquals": {"aws:SourceAccount": ""}}, or - delete the statement if it is not needed. 5. Choose **Save**. 6. Repeat for each affected queue in each region in use. **CLI:** The suggested command passes the policy inline, which the AWS CLI cannot parse, so the policy is passed in a file instead. The command replaces the whole policy, so add any other statements the queue still needs. Save the following as attributes.json: {"Policy": "{\\"Version\\":\\"2012-10-17\\",\\"Statement\\":\[{\\"Sid\\":\\"OwnerAccountAccess\\",\\"Effect\\":\\"Allow\\",\\"Principal\\":{\\"AWS\\":\\"arn:aws:iam:::root\\"},\\"Action\\":\\"sqs:\*\\",\\"Resource\\":\\"\\"}\]}"} Apply the policy to the queue: aws sqs set-queue-attributes --region --queue-url --attributes file://attributes.json **Backout Plan** Before making changes, save the current queue policy: aws sqs get-queue-attributes --region --queue-url --attribute-names Policy --query "Attributes" > queue-policy-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon SQS console, select **Queues** and select the queue. 3. Choose **Edit** and, in the **Access policy** section, paste back the saved policy (the value of Policy in the backup file, without the escape characters). 4. Choose **Save**. **CLI:** aws sqs set-queue-attributes --region --queue-url --attributes file://queue-policy-backup.json Note: rolling back makes the queue public again. Use it only as a temporary measure while the required principals are allowed explicitly. **Reference** - [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-examples-of-sqs-policies.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-examples-of-sqs-policies.html) - [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-best-practices.html) - [https://docs.aws.amazon.com/cli/latest/reference/sqs/set-queue-attributes.html](https://docs.aws.amazon.com/cli/latest/reference/sqs/set-queue-attributes.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.