Introduction

A public backup bucket can expose far more than a live website. Backup archives often contain database dumps, environment files, application code, uploads, and credentials that let an attacker move from read access to full compromise. The fix is to remove public access immediately, determine what was exposed, and treat the bucket contents as potentially accessed until you can prove otherwise.

Symptoms

  • Backup files in cloud object storage can be opened or downloaded without authentication
  • A scanner, search engine result, or third party reports a public storage bucket tied to your site
  • The bucket contains database exports, compressed site backups, media archives, or configuration files
  • Backup URLs work directly from the browser even though the data should be private
  • You cannot confirm whether anonymous users or bots downloaded the files already

Common Causes

  • A storage bucket was created with public read access for testing and never locked down
  • Backup tooling wrote archives to a bucket that inherited overly permissive access settings
  • A bucket policy, ACL, or object-level permission was broader than intended
  • Temporary sharing was enabled for migration or vendor access and not removed afterward
  • Teams assumed backups were safe because the bucket name was hard to guess

Step-by-Step Fix

  1. Remove public access from the bucket and affected objects immediately by disabling anonymous read access and revoking any overly broad bucket or object permissions.
  2. Identify exactly which backup files were exposed so you can assess whether databases, credentials, user files, or application source were included.
  3. Review storage access logs, CDN logs, and cloud audit logs to determine whether the bucket or objects were listed, read, or downloaded.
  4. Rotate any secrets stored in exposed backups, including database passwords, API keys, SMTP credentials, application secrets, and cloud access tokens.
  5. Treat database dumps and user content as potentially disclosed if you cannot rule out access, and follow your incident response and notification requirements where applicable.
  6. Search for other public buckets, old backup prefixes, and shared snapshots so you do not leave related backup data exposed elsewhere.
  7. Move backups into private storage with least-privilege access, encryption, retention rules, and separate access controls from the live application.
  8. Re-test access from an unauthenticated session to confirm the bucket and exposed objects are no longer publicly reachable.
  9. Update backup automation and cloud security guardrails so new buckets and objects cannot become public without deliberate review.