S3 buckets should restrict cross-account permissions

An S3 bucket policy that allows cross-account principals to change permissions creates a privilege escalation path. An external account could grant itself broader access, exfiltrate data, or silently remove protections like encryption requirements. This is a documented attack path in cloud penetration testing engagements.

Explicit deny statements override any allow, including those from the bucket-owning account's IAM policies. Without them, you're relying on the absence of grants, which is fragile as policies evolve and teams add cross-account sharing over time.

Implementation

Choose the approach that matches how you manage Terraform.

module "s3_bucket" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = ">=5.0.0"

  bucket = "abc123"
}

module "s3_bucket" {
  source  = "nistcsf.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = ">=5.0.0"

  bucket = "abc123"
}

module "s3_bucket" {
  source  = "acscessentialeight.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = ">=5.0.0"

  bucket = "abc123"
}

module "s3_bucket" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/s3-bucket/aws"
  version = ">=5.0.0"

  bucket = "abc123"
}

module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = ">=5.0.0"

  bucket = "abc123"
}

resource "aws_s3_bucket" "this" {
  bucket        = "pofix-abc123"
  force_destroy = true
}

resource "aws_s3_bucket_policy" "this" {
  bucket = "example-bucket-abc123"
  policy = jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Deny", Principal = "*", Action = "s3:*", Resource = ["arn:aws:s3:::example-bucket-abc123", "arn:aws:s3:::example-bucket-abc123/*"], Condition = { Bool = { "aws:SecureTransport" = "false" } } }] })
}

What this control checks

This control validates that every S3 bucket has an aws_s3_bucket_policy resource whose policy document contains explicit Deny statements targeting cross-account principals for permission-altering actions. The actions to deny include s3:PutBucketPolicy, s3:DeleteBucketPolicy, s3:PutBucketAcl, and s3:PutObjectAcl. The deny statement needs a Condition block with StringNotEquals on aws:PrincipalAccount (or aws:PrincipalOrgID for org-scoped deployments) to exempt the owning account while blocking all others.

A bucket with no bucket policy, or a policy that omits these deny statements, fails. A bucket using aws_s3_bucket_public_access_block alone also fails because public access blocks don't restrict authenticated cross-account access. The policy argument must contain the deny logic as a valid JSON policy document, typically built with aws_iam_policy_document data sources.

Common pitfalls

Audit evidence

Auditors expect the actual bucket policy JSON for each in-scope bucket, confirming explicit Deny statements covering the permission-modification actions. AWS Config rule results (custom rule or conformance pack) showing compliant status across all buckets provide continuous evidence. S3 console screenshots of the policy tab work as point-in-time evidence but should be supplemented with automated scan output.

CloudTrail logs showing PutBucketPolicy events confirm when policies were applied and by whom, establishing a change history. CSPM tool findings that flag buckets missing cross-account deny statements provide an independent verification layer.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

• Compliance.tf Control: s3_bucket_policy_restricts_cross_account_permission_changes

• Powerpipe Control: aws_compliance.control.s3_bucket_policy_restricts_cross_account_permission_changes

• Prowler Check: s3_bucket_cross_account_access

• AWS Security Hub Control: S3.6

Last reviewed: 2026-03-09