Learn / Attack archive / Lesson 28

Open buckets and default passwords

The breaches that needed no hacking at all — an app that left its users' ID photos public, a hiring bot with the password 123456, and the Philippine voter leak — and why "private by default" matters.

Last updated: 2026-09-23

What it is

Some of the biggest leaks involve no exploit, no malware and no phishing. Something was simply left open:

• A cloud storage bucket (Firebase, S3, Google Cloud Storage) set to public, or never given rules.
• A database reachable from the internet with no password, or the default one.
• An admin or test account with a password like admin or 123456, left over from setup.
• An API that trusts the ID in the URL, so changing /applicants/100 to /applicants/101 shows someone else's record. This is called an IDOR, an insecure direct object reference.

Search engines for exposed devices (Shodan, Censys) and bucket scanners find these within hours of them going live. Researchers find some. Criminals find the rest.

Why it is a rule

• COMELEC, March 2016. Hackers defaced the Philippine Commission on Elections website, and a second group then posted the voter database online: records of about 55 million registered voters, including fingerprint data and passport details for overseas voters. It remains one of the largest government data leaks anywhere. The National Privacy Commission found the chairman criminally liable for failing to protect the data.
• McDonald's McHire, June 2025. The hiring chatbot run by Paradox.ai had a test admin account with the username and password 123456, and no second factor. Inside, an IDOR in the applicant API let researchers page through records by changing a number. About 64 million job-application records were reachable.
• The Tea app, July 2025. A dating-safety app that asked women to upload a selfie and a photo ID to verify themselves stored them in a Firebase bucket that anyone could list and download. About 72,000 images, including 13,000 selfies and IDs, were posted online. A second exposure leaked private messages days later.
• 149 million logins, January 2026. Even criminals do it: the stealer-log database in Stolen logins and infostealers was found because its owners left it open.

Why it keeps working

• Development settings reach production. "Allow all" rules make testing easy and are never tightened.
• Test accounts are forgotten. They were made on day one by someone who has since left.
• Nobody owns the inventory. A bucket made for one feature three years ago has no owner today.
• Access checks stop at "signed in". The API checks that you are logged in, but not that the record is yours.
• Scanning is cheap. The whole internet can be searched for open databases in an afternoon.

How to do it

1. Private by default, public on purpose

Storage rules start at "deny everything". Make individual files public only through a deliberate step, like a signed URL that expires.

// Firebase Storage rules: only the owner may read or write their own folder
rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{uid}/{file=**} {
      allow read, write: if request.auth != null && request.auth.uid == uid;
    }
  }
}

2. Check ownership on every record

Never trust an ID from the URL or body on its own. Load the record with the current user's scope in the query:

SELECT * FROM applicants WHERE id = $1 AND company_id = $2

If the row belongs to someone else, it is simply not found. Random, unguessable IDs help, but they are a second lock, not the first.

3. No default or shared passwords, ever

Change every default password during setup. Remove test accounts before launch. Put admin panels behind a second factor, even the ones you think nobody knows about.

4. Keep an inventory

List every bucket, database and admin panel, with an owner for each. Delete what has no owner. Cloud providers have tools that flag public buckets; turn them on.

5. Do not collect what you cannot protect

The Tea breach hurt because the app kept ID photos after verifying them. If you only need to check an ID once, check it and delete it.

How we do it here

Every query that reads client data carries the tenant taken from the server-side session, so changing an ID in a URL cannot reach another business's rows. There are no default or shared logins; each person has their own. Pages meant to be opened from a link without signing in, such as a receipt, use a long unguessable code, and only a hash of that code is stored.

Benefits

• Deny-by-default rules turn a forgotten bucket into a broken feature instead of a leak.
• Scoping every query by owner kills IDOR as a class.
• An inventory with owners makes forgotten resources rare.

Disadvantages

• Private-by-default means more work for every file that really should be public.
• Scoping every query adds a parameter everywhere, and one missed query is still a leak.
• Inventories go stale unless someone keeps them current.

Checklist

• Every bucket and database denies access unless a rule allows it.
• Every query that reads user data includes the user's or tenant's scope.
• No default, shared or test accounts exist in production.
• Admin panels require a second factor.
• Every data store has a named owner.
• Sensitive uploads are deleted once they have served their purpose.

Sources

• Ian Carroll and Sam Curry — McHire: 64 million job applications exposed
• OWASP — Insecure Direct Object Reference Prevention Cheat Sheet
• Firebase — Get started with Cloud Storage Security Rules
• National Privacy Commission — Breach reporting
• National Privacy Commission, decision on the COMELEC data breach, January 2017.

Read this lesson as Markdown