object-storage-securitylisted

# 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`](../file-upload-security/SKILL.md). ## 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?* ```bash # 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 --acco