SNS topic policy has a wildcard or missing principal

Review SNS topic principals, permitted actions, and service-integration conditions to restrict unintended message publication.

Description

An SNS topic policy identifies the accounts, roles, or service principals that can access the topic and the actions they may perform. If an Allow statement uses a wildcard Principal, review the complete policy, including its conditions, to ensure that access is adequately restricted. An incomplete policy that omits Principal does not grant access to everyone by default.

Effective permissions depend on Action, Resource, conditions, and restrictions in other policies. Choose condition keys according to their meaning and availability in the request. For example, aws:ResourceAccount identifies the resource owner's account. In applicable requests between AWS services, aws:SourceAccount restricts the account owning the source resource; it is not a condition on the account of a general IAM caller.

Potential impact

  • If principals that do not need to publish messages effectively have sns:Publish permission, unwanted messages can reach the topic and its subscribers.
  • If subscribers trigger automation from received messages, this can cause unintended actions or misleading alerts.
  • Misunderstanding a condition can allow broader access than intended or block a required service integration.

Remediation

  • Identify the accounts, roles, or service principals that need access, and restrict Principal, actions, and the actual topic ARN accordingly.
  • Review condition operators, values, and whether the key is available in the request, as well as key names. Do not use aws:SourceAccount as a condition on the account of a general IAM caller.
  • For AWS service integrations, follow that service's guidance for the service principal and appropriate aws:SourceArn or aws:SourceAccount conditions. Avoid the deprecated aws:SourceOwner key in new integrations. After changing the policy, test that required message publication and delivery still work.

Examples

These excerpts compare a wildcard principal with a source-account condition; they are not complete, deployment-ready policies. In the first example, Version: "2022-05-02" is not a supported policy-language version, Publish lacks a service prefix, and Resource is missing. Use 2012-10-17, sns:Publish, and the target topic's ARN in an actual policy. The ARN and account number in the second example also require validation against the actual environment.

Before

yaml
- name: Create alarm SNS topic community
  community.aws.sns_topic:
    name: "alarms"
    state: present
    display_name: "alarm SNS topic"
    policy:
      Version: "2022-05-02"
      Statement:
        - Action: Publish
          Effect: Allow
          Principal:
            AWS: "*"

After

yaml
- name: Create SNS topic with safe policy
  community.aws.sns_topic:
    name: secure-topic
    display_name: "Secure SNS Topic"
    state: present
    policy:
      Id: secure-topic-policy
      Version: "2012-10-17"
      Statement:
        - Sid: AllowPublishFromSpecificAccount
          Effect: Allow
          Resource: "arn:aws:sns:*:*:secure-topic"
          Principal: "*"
          Action: sns:Publish
          Condition:
            StringEquals:
              aws:SourceAccount: "123456789012"

Explanation:

  • First example: Principal.AWS: "*" does not restrict principals to a particular account or role. Correct the syntax problems above and specify who needs access and which operations they need.
  • Second example: The account number in aws:SourceAccount must identify the owner of the source resource for the applicable AWS service request. Choose the principal and conditions appropriate to the actual integration, and replace the ARN's region and account wildcards with the target topic's values. This condition alone cannot restrict all IAM callers to a particular account.

References