The Tea app breach: a Firebase database left open, then an API that trusted any user

What happened

Tea, a women-only safety app, experienced two separate breaches driven by authentication and authorization failures. Barracuda's analysis describes the first as a standard Firebase database leak — the kind that happens "when security policies are not manually configured," leaving stored data readable. The second was more severe: "any user could use their API key to download other user's chats." The app was reportedly built by a small outsourced team, and the analysis frames the root problem as security not being a concern during the minimum-viable-product phase — a pattern it ties to rushed, under-governed development.

Root cause

Both breaches are the same class: broken access control (OWASP A01, CWE-284). In the first, Firebase's default security rules were never tightened, so the datastore was reachable without proper authorization. In the second, the backend accepted a legitimately-issued API key but failed to check that the requested resource belonged to the caller — a classic insecure-direct-object-reference: valid authentication, absent authorization. The app functioned for its users; the invariant "user A cannot fetch user B's data" was never enforced or tested. Security added "later" meant security added after the breach.

How it would have been caught

Two tests. First, connect to the Firebase project unauthenticated and assert reads are denied — red against default rules. Second, authenticate as user A and request user B's chat by id, asserting the API returns denied, not the data — red against the IDOR. Both are direct reproductions requiring two test users and one crafted request; neither shows up in single-user happy-path testing.

How to prevent it

• Configure Firebase Security Rules explicitly, deny-by-default, scoping every record to its owner's uid; cover them with the Rules emulator in CI.
• Enforce object-level authorization on every API endpoint: authentication proves who you are, authorization proves you may touch this specific resource.
• Build the access-control gate into the MVP, not a later hardening pass — the MVP is what ships and gets breached.

The Breachwire test (red → green)

Authenticate as user A and request user B's chat/record by id, and confirm the API returns B's data (and that an unauthenticated client can read the Firebase store) — the RED proof authorization is missing. Add owner-scoped Firebase rules and per-request object-level checks, then confirm A's request for B's data is denied and unauthenticated reads fail, while each user still reads only their own.