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

S3 bucket policy combines wildcard principals with delete actions

Allowing wildcard principals to delete S3 resources can permit unintended object deletion or configuration removal. Limit access to necessary principals, actions, and resources, and verify conditions and recovery options.

Description

A bucket policy that grants delete actions to wildcard principals can give permissions beyond the users or services that need them. Effective access depends on policy conditions, resource scope, explicit denies, and Block Public Access. A conditional wildcard grant is not necessarily unrestricted deletion permission for the entire internet.

Deletion-related actions can remove policies or configuration as well as objects. With bucket versioning enabled, DeleteObject without a version ID creates a delete marker; permanently deleting a particular version requires s3:DeleteObjectVersion. Check the actions actually allowed and the bucket's state separately.

Potential impact

  • Principals that do not need deletion permission may remove objects or make the current object unavailable through a delete marker.
  • Losing objects or configuration needed by a service can interrupt that service.
  • Recovery may depend on retained versions and backups. Versioning alone does not prevent every permanent deletion.

Remediation

  • Limit deletion permissions to the necessary roles, exact actions, and bucket or object ARNs. Remove broad permissions such as s3:*.
  • Review conditions, explicit denies, and Block Public Access across the complete policy, and confirm which policy is applied. A custom policy in S3 module 3.7.0 requires attach_policy = true.
  • Separate object-deletion and version-deletion permissions and test recovery procedures. Confirm that approved cleanup tasks still work while unapproved deletion requests are denied.

Examples

Define the referenced aws_s3_bucket.example separately. 203.0.113.10/32 is a documentation address; replace it with the actual request source. These examples describe different configurations, not two policies to apply to the same bucket together.

Allow deletion with an IP condition

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

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

This statement permits object deletion for requests meeting the IP condition, without restricting the principal to a particular role. Users sharing a source address do not necessarily all need deletion permission; specify the approved roles too.

Explicit deny with an IP condition

hcl
resource "aws_s3_bucket_policy" "delete_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 meeting the specified IP condition. It neither blocks requests from other IP addresses nor provides a complete restriction of deletion to approved roles. Review allows and denies across the full policy so that legitimate users are not blocked.

References

XEIZE DocumentationTechnical support