What are common S3 bucket misconfigurations and how do you prevent them?
Short answer
The classic mistakes are public ACLs or bucket policies that allow anonymous or all-AWS-users access, overly broad principals or wildcard actions, no default encryption, and no logging. Prevent them by enabling account-level Block Public Access, using IAM/bucket policies with least privilege, enforcing default encryption and TLS, and turning on access logging and Config rules to catch drift.
S3 misconfiguration is the textbook cloud breach because object storage is easy to make public and the consequences — millions of exposed records — are severe. The interview wants to know you understand why these leaks keep happening and how to make exposure structurally hard.
The common mistakes
- Public ACLs / bucket policies. Granting
AllUsers(anyone on the internet) orAuthenticatedUsers(any AWS account, not just yours — a frequent trap) read access. - Wildcard principals or actions. A policy with
"Principal": "*"or"Action": "s3:*"is far broader than intended. - No default encryption and no requirement that requests use TLS, so objects can be read or written in clear text.
- No access logging or object-level CloudTrail, so a leak goes unnoticed and is hard to investigate.
How to prevent them
- Block Public Access at the account level. This overrides individual bucket settings and is the single highest-value control — it makes "accidentally public" almost impossible.
- Least-privilege policies. Name specific principals, scope actions, and prefer IAM roles over broad bucket policies.
- Enforce encryption and TLS. Turn on default encryption and add a policy condition denying requests where
aws:SecureTransportis false. - Detect drift. Use Config rules or a CSPM tool to continuously flag any bucket that becomes public or loses encryption.
The key insight: encryption at rest does not stop an anonymous read if the policy allows it — the service decrypts transparently for an authorized request, and a public policy makes the world "authorized."
What interviewers look for
Naming Block Public Access first, distinguishing AllUsers from AuthenticatedUsers, and knowing that detection and prevention both matter.
Likely follow-ups
- What does S3 Block Public Access actually block, and at what levels?
- How would you detect a publicly readable bucket across hundreds of accounts?
- Why doesn't encryption at rest help if the bucket policy allows anonymous reads?