The Tea App Breach: How a Firebase Bucket Exposed 72,000 IDs

If you run an app that stores anything personal — photos, documents, ID images — the Tea app breach is the case study to understand. It's not a story about sophisticated hackers. It's a story about a single misconfigured file bucket, the kind any app can ship with, and the very real harm that followed.

The short version: in July 2025, an unsecured legacy Firebase storage bucket exposed roughly 72,000 images, including about 13,000 selfies and government IDs. A second breach exposed more than 1.1 million private direct messages. The fallout is now consolidated class-action litigation in California.

This post explains what happened, what actually caused it (it was not the part most people panic about), how to check whether your own buckets have the same gap, and how to close it. We'll keep it factual — this involved real people whose ID photos ended up exposed.

⚡ TL;DR

• The root cause was an open Firebase Storage bucket — missing or permissive Storage rules on files that should have been locked to their owners. Not a cracked API key.
• Firebase Storage has its own rulebook, separate from your database. Locking the database does nothing for an open bucket.
• You can check your own Storage rules in a few minutes. If your app accepts uploads, this is the highest-stakes setting you have.

What happened in the Tea app breach

The Tea app is a women's safety and dating-discussion app. To use parts of it, users submitted personal images, including selfies and photos of government IDs, for verification.

In July 2025, those images were found to be publicly accessible. An unsecured legacy Firebase storage bucket exposed roughly 72,000 images, of which about 13,000 were selfies and government IDs. Because the bucket wasn't locked, the files could be reached without authenticating as the user they belonged to.

A second breach followed, exposing more than 1.1 million private direct messages between users. Together, the incidents turned a safety-focused app into a source of the exact exposure it was meant to prevent.

The legal consequences are ongoing: the matter is now consolidated class-action litigation in California. That's the durable lesson — for an app holding ID photos and private messages, a storage misconfiguration isn't only a technical bug; it becomes a legal and human problem.

The root cause: an open bucket, not a leaked key

Here's the part that matters most for your own app, because it's where intuition usually points the wrong way.

When founders hear "Firebase breach," many immediately think of the Firebase config sitting in their frontend — the apiKey and project ID visible in the browser — and assume that was the leak. It wasn't, and it almost never is.

🐺 Not a real problem

The Tea app breach was not caused by the public Firebase web config. The apiKey in a Firebase app is public by design — it identifies your project, it doesn't grant access. Rotating it would have changed nothing here. The cause was an open Storage bucket: file-access rules that didn't restrict who could read the files.

Firebase Storage — where uploaded files live — is governed by its own set of Security Rules, completely separate from the rules on your database. This separation is the trap. A team can lock down their Firestore database, confirm users can only read their own records, and feel secure — while the file bucket holding everyone's uploaded images sits under a different, permissive rule that nobody tightened.

An open Storage rule looks like this, and it means anyone who can reach the bucket can read its files:

// An open Storage bucket: files readable without ownership checks
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if true;
    }
  }
}

The word "legacy" in the reports matters too: it points to an older bucket that was set up earlier, perhaps before stricter rules were applied elsewhere, and then forgotten. Old, unmonitored storage is exactly where this kind of gap survives — the app keeps working, the files keep loading, and nothing signals that they're also loading for strangers.

Why this pattern is so common

Open buckets aren't a Tea-app-specific failure. They're a structural blind spot, and AI builders make them more likely, not less.

When you ask a tool to "let users upload a profile photo," it wires up Firebase Storage so the upload works in the preview. Permissive Storage rules make that work immediately — the image saves, the image displays, the feature looks done. Tightening the rules to "only the owner can read this file" is extra work that doesn't change anything you can see in a demo. So it often doesn't happen.

Two structural facts make it worse:

• Storage rules are separate from database rules, so "I secured my database" gives false comfort about files.
• Files are reachable by URL, so an exposed bucket doesn't require breaking into anything — it only requires the address.

The result is a category of breach where nobody is "hacked" in the dramatic sense. The data was plainly readable, and someone read it.

How to check your own app

You can't change what happened to Tea's users, but you can make sure your app isn't carrying the same gap. This takes a few minutes and no code, and it's the one check that would have caught this breach.

1. Open the Firebase Console → Storage → Rules. Read the rule. If you see allow read: if true; or allow read, write: if true;, your bucket is open to anyone who finds a file URL.
2. Check this separately from your database rules. Do not assume a locked database means locked files. They're different rulebooks. This is the single most important takeaway.
3. Look for old or unused buckets. If your project has more than one storage bucket, or one created early in the project's life, check each. "Legacy" buckets are where forgotten open rules live.
4. Confirm rules tie files to owners. A safe rule scopes access to the file's owner, usually by putting each user's files under their own UID path and checking it.
5. Test the way an outsider would. Copy a file URL from your app's network traffic and try opening it in a private browser window with no login. If the file loads, anyone can load it.

The fix

If your bucket is open, the remedy is to scope every file to its owner. The reliable pattern is to store each user's files under a path that includes their user ID, then require that the requester's ID matches:

// Lock Storage so users can read and write only their own files
service firebase.storage {
  match /b/{bucket}/o {
    match /user-uploads/{userId}/{fileName} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
  }
}

A few practical notes:

• Match the path to where your app actually writes files. If your uploads land somewhere else, point the rule there, or the rule protects an empty path while the real files stay open.
• Handle sensitive verification files most strictly. ID photos and selfies usually shouldn't be readable from the client at all after upload — consider rules that allow the user to write but only your server (via the Admin SDK) to read.
• Audit every bucket, including old ones. The fix only helps the buckets you remember to apply it to.

For the full treatment of Storage rules — public-by-default pitfalls, per-user paths, and validation — see open Storage buckets: the #1 Firebase leak. For the broader picture of how Firebase security fits together, start with Firebase security for AI-built apps.

Where Tea fits in the bigger pattern

The Tea breach didn't happen in isolation. It's one entry in a run of incidents on AI-built apps where a single missing rule exposed real user data — alongside cases like Enrichlead, Base44, and Moltbook. The common thread isn't exotic attacks; it's default-open configurations that ship because they work in the preview. We trace the full sequence in the vibe-coding breach timeline.

How Is My Site Hackable? catches open buckets

Open buckets persist because they're invisible from inside your own app — everything loads, so nothing looks wrong. The only honest way to find one is to probe the deployed app from the outside, the way an attacker would, and see whether files come back without authorization.

That's what Is My Site Hackable? does: it scans your live app, checks whether your Storage responds to unauthenticated requests, and reports buckets that are actually readable — while filtering out the public web config that isn't a problem. You get a clear answer to the one question that mattered for Tea: can a stranger read my users' files?

FAQ

What caused the Tea app data breach?

An unsecured legacy Firebase storage bucket. Its access rules didn't restrict who could read the files, so roughly 72,000 images — including about 13,000 selfies and government IDs — were publicly reachable. A second breach exposed more than 1.1 million private direct messages. The cause was misconfigured Storage rules, not a leaked or cracked API key.

Was the Tea app breach caused by an exposed API key?

No. The Firebase web config / apiKey is public by design and was not the issue. The breach came from an open Storage bucket — file-access rules that didn't enforce ownership. This is a common point of confusion: the public config gets the blame, but the real failure is almost always permissive rules.

How do I know if my Firebase Storage bucket is exposed?

Open the Firebase Console → Storage → Rules and check for allow read: if true. Then test from outside: copy a file URL from your app and open it in a private browser window with no login. If the file loads, your bucket is exposed. Check this separately from your database rules — they're different rulebooks.

Is Firebase Storage secured by my database rules?

No. Firebase Storage uses its own Security Rules, completely separate from your Firestore or Realtime Database rules. A fully locked database can sit right next to a wide-open file bucket. You have to review and lock Storage rules on their own.

The bottom line

The Tea app breach is the clearest reminder that, in Firebase, your files are only as safe as their Storage rules — and those rules are separate from everything else you secured. No key was cracked; a bucket was left open, and real people's ID photos and private messages were exposed. An attacker can find an open bucket in minutes by reading a file URL, so the job is to find it first — and to keep checking, because every time your AI adds an upload feature or a new bucket, it can quietly reopen this exact gap.