In the last week of July 2025, Tea had just climbed to the top of Apple's App Store. It's a dating safety app for women: users share experiences about men they've dated, and to join you prove you're a woman by uploading a selfie and, for many users, a photo of a government ID.
On 25 July, someone posted on 4chan that Tea's verification images were sitting in an open Firebase storage bucket, with a link to it. 404 Media matched the bucket to the address in Tea's Android app code. Within hours the images were being passed around.
Tea confirmed the incident. Its statement said 72,000 images were exposed: about 13,000 selfies and photo IDs submitted during account verification, and 59,000 images that had been publicly viewable in the app from posts, comments and direct messages. The company said the data came from a "legacy data storage system" and involved users who signed up before February 2024.
Days later, a separate researcher reported that a different part of Tea's system exposed more than a million private messages.
What "an open bucket" means
Most apps that accept uploads, whether profile photos, documents or receipts, don't keep those files in the database. They put them in a storage bucket, which is a cloud folder for files. Firebase has one, Supabase has one, Amazon has S3.
Each bucket has its own access rules, and they're separate from your database rules. You can lock your database perfectly and still leave the bucket readable by anyone with its address. According to reporting on the incident, that's the situation Tea was in: the bucket allowed public reads, and the address was sitting in the app's own code, where anyone could find it.
It's an easy mistake to make, which is why it keeps happening. When you're setting up uploads, the fastest way to get images to display is to make the bucket public. The feature works. Nothing tells you that every other file in there is now public too.
The part that made it worse: old data
Tea's privacy policy at the time said verification photos were processed securely and deleted after verification. The leaked set came from before February 2024, which suggests those images had been kept long after they were needed. Tea's explanation, reported by Engadget, was that the data had been stored in line with law enforcement requirements related to cyberbullying prevention.
Whatever the reason, the effect is the same. Files that no longer served users were still there when the lock failed. The cheapest security there is comes from not holding data you don't need.
If your users are in Europe, this isn't only a good idea. GDPR requires you to keep personal data no longer than necessary for the purpose you collected it for, and ID images are exactly the kind of data regulators care about.
Check your own storage in five minutes
You don't need to read code for this.
- Upload a test file in your app as a normal user, something only that user should see, such as a private document or an avatar on a private profile.
- Find the file's URL. Right-click the image and copy its address, or look in the browser's Network tab.
- Open a private browsing window where you're not signed in, and paste the URL.
- If the file loads, anyone with the link can see it. That may be fine for public avatars. It is not fine for IDs, invoices, medical documents or anything a user uploaded expecting privacy.
- Now try guessing a neighbour. Many apps name files predictably, like
user_123/id.jpg. Change the number. If you can open someone else's file, your storage is effectively public.
Then open your storage settings. In Firebase, go to Storage, then Rules, and look for anything that allows read without checking request.auth. In Supabase, go to Storage, see which buckets are marked Public, and read the policies on the private ones. Ask your AI coding tool to explain each rule in one sentence. If it can't explain who is allowed to read a file, fix that rule first.
Three habits worth stealing from this
Keep sensitive uploads in a private bucket and serve them with short-lived signed links, which your AI tool can set up in a few minutes.
Delete verification data as soon as verification is done, or use an identity verification provider so the images never touch your storage at all.
Put your bucket rules on the same checklist as your database rules. Our pre-launch security checklist treats them as separate items for exactly this reason: they fail separately.