XEIZE
/Vulnerability documentation/IaC/Terraform/AWS/S3 bucket policy combines wildcard principals with put actions

S3 bucket policy combines wildcard principals with put actions

Granting S3 Put actions to wildcard principals can allow unnecessary uploads or configuration changes. Limit each operation to the roles and resources that need it and check effective access controls.

Description

Granting Put actions to wildcard principals can extend write permissions beyond the intended users or services. These actions include configuration changes, such as ACL updates, as well as object uploads. Effective access depends on the actions, resource ARNs, conditions, explicit denies, and Block Public Access.

PutObject permission can allow new objects or changes to the current contents at an existing key. When versioning is enabled, writing to the same key creates a new version. Even if older versions remain, applications using the current object may read the changed data.

Potential impact

  • Principals that do not need upload access may add unwanted content or increase storage costs.
  • Writes to an existing key can change content read by an application or deployment system.
  • Permissions to change configuration can alter access controls or operational settings. Distinguish upload permission from administration permissions.

Remediation

  • Restrict uploads and configuration changes to the roles and actions needed for each operation, using appropriate bucket or object ARNs. A need for public reads does not justify public writes.
  • Review conditions, explicit denies, ACLs, and Block Public Access across the full policy. Confirm that the module applies the policy; a custom policy in S3 module 3.7.0 requires attach_policy = true.
  • Test legitimate uploads and unapproved write requests, and verify versioning and recovery procedures. Do not grant ACL or bucket-policy administration to a role that only needs to upload objects.

Examples

Define aws_s3_bucket.example separately. 203.0.113.10/32 is a documentation address; replace it with the actual source address. These examples represent different policies and must not be applied to the same bucket together.

Allow object writes with an IP condition

hcl
resource "aws_s3_bucket_policy" "put_open_policy" {
  bucket = aws_s3_bucket.example.id

  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Id": "MYBUCKETPOLICY",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "${aws_s3_bucket.example.arn}/*",
      "Condition": {
         "IpAddress": {"aws:SourceIp": "203.0.113.10/32"}
      }
    }
  ]
}
POLICY
}

The IP condition limits applicable requests, but does not restrict upload principals to a particular role. Users sharing the source address may receive unnecessary write access, so identify the approved roles.

Explicit deny with an IP condition

hcl
resource "aws_s3_bucket_policy" "put_restricted_policy" {
  bucket = aws_s3_bucket.example.id

  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Id": "MYBUCKETPOLICY",
  "Statement": [
    {
      "Sid": "IPDeny",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "${aws_s3_bucket.example.arn}/*",
      "Condition": {
         "IpAddress": {"aws:SourceIp": "203.0.113.10/32"}
      }
    }
  ]
}
POLICY
}

This deny applies only to object operations from the specified IP address; it does not restrict write permissions from other sources. It does not replace limiting uploads to approved principals and may block legitimate requests. Review it alongside all applicable allows and denies.

References

XEIZE DocumentationTechnical support