S3 Misconfigs I Keep Seeing in the Wild

Every cloud security engagement I’ve done has at least one S3 finding. Usually more. Here are the ones that keep showing up.

Public Access Block Not Enabled

This is the big one. AWS added the S3 Block Public Access settings specifically to prevent accidental exposure, but teams still disable it — usually because something broke and they took the easy way out.

aws s3api get-public-access-block --bucket your-bucket-name

All four settings should be true. If any are false, that’s a finding.

Overly Permissive Bucket Policies

Bucket policies with "Principal": "*" and no conditions are a red flag. Even if the bucket isn’t technically public, a wildcard principal means any authenticated AWS user can access it.

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

That policy above? That’s a data breach waiting to happen.

No Server-Side Encryption

S3 encrypts at rest by default now (SSE-S3), but a lot of older buckets predate that default. Always verify, and for sensitive data you want SSE-KMS with a customer-managed key so you control the key policy.

Access Logging Disabled

You can’t investigate what you can’t see. S3 access logging should be enabled on any bucket holding sensitive data. It’s cheap and the forensic value is high.

The Fix

Run this across all your buckets and you’ll catch most of it:

aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  tr '\t' '\n' | \
  xargs -I {} aws s3api get-bucket-policy-status --bucket {}

More on automating this with AWS Config in a future post.