How not to spill the Tea: A real-world app security lesson
Tea, a women-only dating advice app, was built around a simple idea: users anonymously review and share notes about men they dated, from charming quirks to serious red flags. It marketed itself as a digital whisper network, a place to trade wisdom and warnings in a way that felt empowering and communal.
However, beneath the sleek branding and viral buzz, the app had the unmistakable fingerprints of a first-time coder: patchwork features, inconsistent performance and a backend architecture that seemed cobbled together with more enthusiasm than expertise.
Those poor decisions inevitably came back to haunt them.
The Tea hack explained
The first breach occurred in late July 2025, when hackers gained access to a legacy Google Firebase storage bucket that was overlooked during Tea’s migration to more secure infrastructure. This unsecured bucket contained over 72,000 images, including 13,000 photos of users holding government-issued ID cards (part of Tea’s early verification process) and 59,000 other images from posts, private messages, and comments. Although the company had since moved to stricter authentication systems, the legacy data remained exposed and accessible to attackers, who swiftly dumped the content online.
The second breach was even more damaging. Just days later, over 1.1 million private messages exchanged between Tea users from February 2023 to July 2025 were leaked. These messages were meant to be confidential, often containing deeply personal accounts of relationships, trauma, abuse, and intimate experiences. Many of them included names, phone numbers, and specific meeting locations, making it possible to identify not only the men discussed but also the women who submitted the reports. Although Tea claimed that core contact data like emails and phone numbers weren’t part of the leak, the content of the messages themselves often included that information, voluntarily shared between users.
Both of these “hacks” were due to a beginner-level mistake: providing direct unauthenticated access from the client to the data on the back end. It has been speculated that the app was “vibe coded” and this was a result, but it seems to me far more likely that this was a consequence of a beginner programmer that doesn’t understand appropriate ap security.
The consequences
The data was downloaded and dumped to the internet and from there it was leveraged to extract more information. The pictures still mostly contained location metadata, which was quickly used to provide a map showing the location of the photos. Some of these were on sensitive locations, including military bases.
The private messages contained locations and phone numbers, which were then combined with the geolocation data on the photos to link photos to messages.
This level of data means that identity fraud would be very likely for those included in the breach.
For the company itself, multiple class action lawsuits have been consolidated into a single federal suit in California. The plaintiffs allege Tea failed to take reasonable steps to secure users’ sensitive data, and delayed notifications of the breaches.
How Tea violated basic app security principles
All of this could have been avoided had Tea not violated several basic app security best practices.
Restrict to least-required access
First, it failed to implement the principle of least access, which ensures that systems and users only have the minimum permissions necessary to perform their functions. Instead, Tea’s early architecture granted the client-side app direct access to a cloud storage bucket, which effectively exposed a broad attack surface to anyone with the right tools or curiosity.
Keep credentials out of the code
The developer also made another cardinal error: including the Google cloud access key in the environment files for the app. Perhaps they thought because Tea was a phone app no one could find the keys. This was a beginner level mistake. Nothing that runs on the client should ever have direct access to the data storage.
Secure all infrastructure, including legacy systems
Just as importantly, it’s essential to secure all resources, not just the ones currently in use. Legacy systems, old storage paths and deprecated services still pose risks if left exposed.
A more secure design would have placed the legacy storage bucket behind a tightly controlled backend API, with authentication and authorization handled server-side, to ensure that only validated and rate-limited requests could access specific resources. No user, and certainly no app front end, should ever have had unrestricted access to raw storage.
Testing is part of secure app development
Thorough testing should have caught these vulnerabilities long before they reached production.
Security testing, especially around data access, storage permissions, and API boundaries, is a critical part of responsible development, not an afterthought. Proper test protocols and tools would have flagged the exposure of sensitive credentials, the misconfiguration of public storage buckets and the absence of access controls. Most professional IDEs would have warned about putting API keys into a client environment file.
Security is not a destination, it is a process that needs to constantly evolve with your application.
The breaches at Tea are catastrophic, to both users and to the brand. But they were not the result of sophisticated cyberattacks — they were the consequence of painfully basic security oversights:
- Exposing storage buckets to the client.
- Embedding access credentials in the frontend.
- Failing to audit or decommission outdated infrastructure.
Even entry-level security checklists warn against such mistakes. These weren’t flaws in advanced cryptography or zero-day exploits. They were avoidable errors, stemming from inexperience and a lack of secure development practices.
David “Walker” Aldridge is a programmer with 40 years of experience in multiple languages and remote programming. He is also an experienced systems admin and infosec blue team member with interest in retrocomputing.