S3 bucket policies are JSON-based resource policies that control who can access your S3 buckets and objects, and what they can do. A misconfigured policy is one of the most common causes of AWS data breaches — the Capital One breach (2019, 100M+ records) and thousands of other incidents were caused by overly permissive S3 policies. This validator checks your policy against AWS security best practices, CIS AWS Foundations Benchmark, and OWASP Cloud Security guidelines — entirely in your browser.
What makes an S3 bucket policy dangerous?
The most dangerous patterns are: Principal set to "*" (allows any internet user), Action set to "s3:*" (all S3 operations), missing Condition blocks (no IP/VPC/MFA restrictions), NotPrincipal with Allow effect (accidentally allows everyone except listed principals), and cross-account access without ExternalId conditions.
What is the difference between a bucket policy and ACLs?
Bucket policies are JSON documents attached to the bucket that use IAM policy language. ACLs (Access Control Lists) are a legacy mechanism that assigns predefined permissions to AWS accounts or groups. AWS recommends disabling ACLs (Object Ownership = Bucket owner enforced) and using bucket policies exclusively for finer-grained, auditable access control.
How does S3 Block Public Access work with bucket policies?
S3 Block Public Access (BPA) is a guardrail that overrides bucket policies and ACLs. Even if your policy allows public access, BPA will block it at the account or bucket level. There are 4 BPA settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. All four should be enabled for any bucket that doesn't need to be public.
What is the aws:SecureTransport condition and why is it important?
The aws:SecureTransport condition key evaluates to true only when the request is sent over HTTPS (TLS). Adding a Deny statement with "aws:SecureTransport": "false" forces all S3 traffic to be encrypted in transit, preventing credential interception via man-in-the-middle attacks. This is a CIS AWS Benchmark requirement.
What S3 actions are considered high-risk?
High-risk actions: s3:DeleteObject, s3:DeleteBucket, s3:PutBucketPolicy (can replace your security policy), s3:PutBucketAcl (can make bucket public), s3:PutObject (data exfiltration risk), s3:GetObject on sensitive buckets, s3:ListBucket (reveals object keys), and s3:* wildcard. These should always have restrictive Condition blocks.
How do I allow CloudFront to access a private S3 bucket securely?
Use Origin Access Control (OAC), the modern replacement for Origin Access Identity (OAI). Create an OAC in CloudFront, then add a bucket policy granting s3:GetObject to the CloudFront service principal (cloudfront.amazonaws.com) with an aws:SourceArn condition matching your CloudFront distribution ARN. Never use Principal "*" for CloudFront-backed buckets.
