Toutes les vulnérabilités
CRITICALAI/LLMexploited in the wildcurated

AI-TEA-APP-BREACH-2025

Mobile · Firebase · Tea (dating-safety app)

Résumé

Tea was a women's safety app, a place to share warnings about men, which meant it held some of the most sensitive data imaginable: selfies, government IDs, and private messages. In July 2025, just as it hit number one on the US App Store, it turned out that one of its storage buckets was simply open to the internet, no password, directory listing on. Roughly 72,000 images, including 13,000 verification selfies and photo IDs, plus over a million private messages, were exposed and promptly dumped on 4chan, fueling doxxing of the very women the app was meant to protect. Often called a "vibe-coding" disaster, it was actually something older and just as instructive: an app built by outsourced contractors for a founder who could not read the code, with no security review, shipping a misconfigured cloud bucket and a broken-access-control flaw nobody caught.

How it happened

Tea stored user images in a Google Firebase Storage bucket that was configured for public access with directory listing enabled. In plain terms, anyone with the URL could browse and download everything, with no authentication at all. The root cause was not the Firebase API keys embedded in the app (those are designed to be public); it was the missing Firebase Security Rules that should have gated access to the data. That exposed roughly 72,000 images: about 13,000 verification selfies and government IDs (driver's licenses and passports), and about 59,000 from posts and messages.

Then it got worse. A second flaw, a broken-authorization bug, let any logged-in user pull other users' private messages using their own API key, exposing over a million direct messages going back to 2023, on topics like abortion, infidelity, and assault, often with phone numbers and meetup locations attached. The deeper question is how an app handling government IDs shipped like this at all. Tea's founder has said he cannot code, and the app was built by a pair of contractors hired through Toptal, with no one in a position to review the security of what they shipped. It actually predates the "vibe coding" era it is often blamed on, but the lesson rhymes: code nobody competent reviewed, holding the most sensitive data imaginable.

The damage

The cruelty of it was the point. Tea's users were specifically women sharing safety concerns, and the breach exposed their faces, their real government IDs, and their private messages, the exact material needed to identify, locate, and harass them. It was the most sensitive possible data (a photo ID plus a selfie plus private messages) sitting in the least secure possible container, an unauthenticated public bucket. For the people affected, it inverted the app's entire purpose. The fallout was swift: a wave of class-action lawsuits, biometric-privacy claims, and Apple's removal of the app from the App Store in October 2025.

Why Tea still matters

Tea is the lesson that you cannot outsource security you are unable to review. AI did not write this app, but the failure mode is the same one that AI-assisted vibe coding now mass-produces: working software shipped by someone who cannot, or does not, check it, with the insecure defaults left in place, public buckets, missing access control, retained ID documents a privacy policy promised to delete. The fundamentals that got skipped are exactly the ones that matter: require authentication and proper rules on all storage and never expose a public bucket, enforce per-user authorization so one account cannot read another's data, decommission legacy datastores after a migration, minimise and delete identity documents you no longer need, and run a real security review and pentest before launch. It sits alongside the Replit database wipe as a 2025 warning about shipping code no competent reviewer signed off on.

Comment le corriger

  • Lock down the exposed bucket and datastore immediately (require authentication, add proper access rules, disable public access and directory listing), and confirm no other orphaned stores are open.
  • Add per-user authorization checks so one logged-in account cannot read another's data, and assume all exposed data (IDs, selfies, messages) is permanently compromised.
  • Notify affected users and regulators, and offer identity-protection support, since government IDs cannot be cheaply reissued.

Comment l’éviter

  • Require authentication and proper security rules on all storage buckets; disable public access and directory listing, and never rely on the obscurity of a URL.
  • Enforce per-user (object-level) authorization so one authenticated user cannot read another user's data.
  • Decommission legacy and unsecured datastores after migrations; verify no orphaned exposure remains.
  • Run a security review and pentest before launch, especially for an app holding PII or government IDs, and never ship code no competent reviewer has checked.
  • Minimize and delete sensitive PII (IDs, selfies) you no longer need, and encrypt what you keep.

Références

Vulnérabilités liées

Tout AI/LLM →