Module 3 · S3 Security and Misconfigurations 🔒

Amazon S3 is the single cloud service that has caused more publicly-disclosed breaches than any other — by a wide margin. Hundreds of millions of records from financial institutions, healthcare organisations, government agencies, and consumer apps have leaked from misconfigured S3 buckets. Every single incident was preventable with settings available in the AWS console.

This module is the S3 security practitioner’s guide. You’ll learn what breaks, why, and every layer of defence that has to be configured properly.

Why S3 specifically

S3’s design makes it the ideal data-exfil target:

• Object storage is where data lives — backups, exports, logs, datasets, uploads
• Buckets are globally addressable by name — once found, they’re reachable from anywhere
• S3 has been around since 2006; lots of legacy configurations
• Access controls are layered (IAM, Bucket Policy, ACL, Block Public Access) — multiple opportunities for misconfig
• Bucket contents are often discoverable via predictable naming (companyname-backups, companyname-dev)

The access control stack

For any S3 request, access is determined by a combination of:

1. Block Public Access — account-level and bucket-level overrides that block public access regardless of other settings
2. Bucket Policy — resource-based JSON policy attached to the bucket
3. Bucket ACL — legacy, simple permissions (READ, WRITE, READ_ACP, WRITE_ACP). Generally avoid
4. Object ACL — per-object legacy permissions. Generally avoid
5. IAM Policies on the caller
6. VPC Endpoint Policies (if accessing via VPCE)
7. S3 Access Points — named access delegation with its own policies

Access is allowed only if every applicable layer permits AND no layer denies. Getting this stack aligned is the job.

Block Public Access — the must-enable

Block Public Access (BPA) has four settings, each of which should be ON at both account and bucket level:

• BlockPublicAcls — prevents new public ACLs
• IgnorePublicAcls — ignores existing public ACLs
• BlockPublicPolicy — prevents public bucket policies
• RestrictPublicBuckets — restricts access to buckets with public policies

Enable all four at the account level. This is the single most impactful security setting for S3. It overrides mistakes in individual bucket configs.

aws s3api put-public-access-block \
  --bucket BUCKET_NAME \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# At account level
aws s3control put-public-access-block \
  --account-id 111111111111 \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Classic misconfiguration patterns

Pattern 1 — “AuthenticatedUsers” ACL

S3 legacy ACL granting access to “AuthenticatedUsers” grants access to any AWS account holder in the world, not just your org. Historical finding in 20%+ of audits.

Fix: Enable IgnorePublicAcls. Remove AuthenticatedUsers from all ACLs. Use Bucket Policy with account-scoped Principals instead.

Pattern 2 — Bucket policy with Principal: “*”

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::company-data/*"
}

Anyone on the internet can read every object. Classic breach cause.

Fix: BlockPublicPolicy prevents this. Scope Principals to specific accounts or roles.

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999999999999:root"},
  "Action": "s3:*",
  "Resource": "*"
}