S3 bucket policy uses a wildcard principal

Description

In an S3 bucket policy, Principal: "*" can include anonymous requests as well as other AWS accounts. Granting more access than needed can let unintended callers read or modify objects. Review the whole policy: effective access depends on the allowed actions, resources, conditions, explicit denies, and S3 Block Public Access settings.

Potential impact

Files, logs, or backups may be exposed if unintended principals can actually read objects.
Permitted write or delete operations can affect data integrity or availability. A wildcard principal alone does not grant every operation.

Remediation

Specify the required accounts, roles, or service principals, and limit each action and resource scope to what is needed.
If a wildcard is required with conditions, verify that the condition keys, operators, and values admit only intended requests.
If public access is unnecessary, apply S3 Block Public Access and review the effective account and bucket settings together. Check that required external integrations still work.

Examples

The first example uses ${aws_sqs_queue.q.arn} for Resource. This refers to an SQS resource, so the example cannot be deployed as a valid S3 bucket policy; a real S3 resource ARN is required. In the second example, replace the account and role ARN with actual values and check the related permissions and Block Public Access settings.

Before

yaml

- name: Create a simple s3 bucket with a policy
  amazon.aws.s3_bucket:
    name: mys3bucket
    policy:
      Version: "2012-10-17"
      Id: "sqspolicy"
      Statement:
        - Sid: First
          Effect: Allow
          Principal: "*"
          Action: "*"
          Resource: ${aws_sqs_queue.q.arn}

After