object-storage-security

Object Storage Security

Public-bucket leaks remain one of the top breach causes a decade after S3 launched — not because the controls are missing, but because the defaults were permissive for years and every provider's mental model (bucket policy, ACL, IAM, signed URL, public binding) overlaps just enough to confuse. One public-read flag or one over-broad access key turns a dumb byte store into a data breach.

This skill is the baseline for any S3-compatible store: AWS S3, Cloudflare R2, Google Cloud Storage, self-hosted MinIO. The threat model is the same everywhere — accidental public exposure, over-scoped credentials, exfiltration you never notice, and uploads that come back to bite the app that serves them. For validating the file contents, see file-upload-security.

When to invoke

• Creating a new bucket for an app (uploads, backups, static assets)
• Auditing buckets you inherited and did not provision
• Wiring presigned upload/download URLs into an application
• A credential that had storage access leaked or may have leaked
• Moving from local-disk storage to object storage
• Reviewing ransomware / mass-deletion resilience of stored data

Step 1 — Public access audit

Start by answering one question per bucket: can an unauthenticated stranger read it?

# S3: Block Public Access must be on at BOTH levels
aws s3api get-public-access-block --bucket example-app-uploads
aws s3control get-public-access-block --account-id 123456789012

# Turn it on (account level covers future buckets too)
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Is the policy public per AWS's own analysis?
aws s3api get-bucket-policy-status --bucket example-app-uploads

# Empirical test — should return 403, never a listing
curl -s https://example-app-uploads.s3.amazonaws.com/