S3

When you’re reviewing S3 security, here are things you should always check:

  • Buckets with excessive access (public read, public write, or accessible by low-privileged identities)

  • Bucket policies that allow broad or unintended access (for example "Principal": "*", cross-account access, or weak/misconfigured conditions)

  • Permissions that use wildcards such as "Action": "s3:*" or unrestricted bucket/object ARNs (arn:aws:s3:::bucket/*)

  • Buckets with write access that allow object upload, overwrite, or deletion (PutObject, DeleteObject)

  • AWS services or Lambda functions that read from or write to S3 buckets you can control (S3 as input/output for execution)

  • S3 buckets used as deployment sources (Lambda code, CloudFormation templates, CI/CD artifacts)

  • Buckets containing sensitive data (logs, backups, Terraform state files, database dumps, .env files)

  • Exposed secrets stored in S3 (API keys, credentials, tokens, certificates)

  • Bucket versioning enabled (old object versions may still contain secrets)

  • Bucket error pages or static website hosting indicating S3 presence (inspect source code and references)

  • References to S3 buckets in application source code (hardcoded bucket names often lead to data discovery or abuse)

  • Buckets without proper Public Access Block configuration

  • Cross-account S3 access that may allow lateral movement between AWS accounts

Last updated