The Tea app was once described as the safest place online for single women to ‘spill tea’ or communicate anonymously about their dating experiences with men. On July 25, 2025, however, things reversed course when it was announced that the app’s back-end trove of personal data, including member selfies, driver’s licenses and private communications, had been hacked and exposed. 

Hackers successfully engineered this breach through Tea’s unprotected Google Firebase database. Unfortunately, this failure to holistically address security — even among developers of the world’s most popular mobile apps — is alarmingly more common than one would think. So why does such a critical detail still get overlooked? Often, it’s due to organizational pressure to ship quickly (a ‘ship fast and fix later’ mindset), paired with outdated assumptions about who owns back-end security.  

Security and privacy aren’t features you tack on later — they need to be part of the product’s DNA from day one, at both the front end and the back end. But when it comes to the back end specifically, here’s a snapshot of key ways to fortify defenses. 

Role-Based Access Management Accompanied by Identity Verification  

The Tea hack may have been caused by external bad actors, but it’s important to remember that insider threats (both malicious and negligent), frequently targeted at back-end databases and systems, are still accelerating rapidly. Who can forget the Ashley Madison cyberattack of 2015, which was thought to be an inside job? 

A variety of personnel regularly require access to back-end databases — database administrators, back-end application developers and DevOps and QA testers, to name a few. Role-based access management, enforcing the Principle of Least Privilege, helps ensure that these professionals have the permissions they need to do their jobs. However, outdated identity verification tools — for example, passwords and some forms of multifactor authentication, which are prone to theft, interception and even mass compromise — are no longer sufficient. To be truly effective, role-based access management policies need to be paired with the same types of sophisticated, unmistakable identity verification processes used at the front end, like biometrics and liveness detection.  

Comprehensive Data Lifecycle Management  

With web and mobile apps widely recognized as a top data breach vector, users expect their data — especially identity-related content — to be protected throughout its entire journey, from collection, to storage, to processing and usage and ultimately, archival and destruction.  

Tea’s initial investigation suggested that the hack was limited to a legacy database containing data collected over two years ago. While this may have come as a relief for holders of recently created accounts, it did little to assuage the concerns of longer-term users and begs the question: Did Tea really need to keep all this data for so long in the first place?  

Mobile app platforms need to have policies in place for data erasure at certain intervals — ideally, right after the data is no longer needed. Moreover, just ‘erasing’ a file does not mean the data is really gone, and other data sanitation techniques like cryptographic purging (rendering original data inaccessible once it has been encrypted, and the encryption key deleted) should be considered. 

Vetting AI-Generated Code  

AI can speed up and enhance many software development-related tasks. But it comes with big risks, including developers over-relying on AI output, assuming that code is secure and reducing thorough code reviews and testing. Furthermore, the higher volume and pace of code being shipped can increase the number of vulnerabilities exponentially. One study found that the same AI tools that accelerate coding velocity can result in a tenfold surge in security issues.  

While overall acceleration of code delivery can be a good thing, it risks outpacing security. AI can also lack a deep understanding of an application’s specific security needs and regulatory requirements, leading to code that may be functionally correct but insecure. Developers need to always check AI-generated code to ensure that it is completely secure, from the client side, all the way back to the server side (specifically, how it interacts with the database). At a minimum, teams should set up AI-linting policies, require code review for AI-generated changes and consider tagging or labeling AI-generated code in pull requests. 

Reducing and Managing Third-Party Risks  

Leveraging third parties enables developers to deliver exceptional user experiences, faster — everything from payment gateways for in-app purchases, to social media integrations, to analytics and monitoring. Today, the average mobile application is estimated to feature dozens of integrations, with up to 90% of code sourced from third parties. 

There’s no shortage of examples of data breaches stemming from insecure third-party APIs or infrastructures. In 2024, attackers breached a third-party merchant processor used by American Express to gain a foothold in American Express’s systems and leak sensitive cardholder data such as names, account numbers and expiration dates. Ultimately, American Express had to assume liability for fraudulent charges resulting from the breach. Increased reliance on third parties and the corresponding security risks may not be a new concept for developers, but the reminder is as pertinent as ever. Reduce reliance on external code whenever possible, but when third-party services are integrated, comprehensive security vetting is an absolute must — before, during and after integration.  

These days, any mobile app storing sensitive media needs to think and act like an identity verification company; failing to address back-end database security is not just a technical oversight, but a trust issue. Popular cloud-based database offerings like Google Firebase provide defaults and a solid baseline, but this may not be enough, as secure configuration, access control and data lifecycle management ultimately remain a developer’s responsibility.