Verification files (photos, IDs) submitted by users were stored in a public Firebase storage bucket, allowing anyone with the URLs to access them.
Hundreds of thousands of personal images and IDs from older users (pre-2024) became publicly accessible.
Leaked files also contained metadata, such as information stored in images from iPhones.
Message data from the app was also breached, leading the company to fully shut down the messaging feature.
No new sign-ups post-2024 were affected due to the bucket no longer being used.
Is It a Hack? Discussion of Terms and Misconceptions 05:12
Common misconception: "If the bucket was public, nothing was hacked." The creator disagrees, analogizing it to theft via an unlocked house—still theft.
"Hack" is used to describe both breaking in and unauthorized access/distribution; accessing all URLs is not trivial and required finding an exposed API endpoint.
Hackers located and hit a Firebase endpoint, which listed all files and URLs, enabling mass downloading of sensitive data.
The incident was not due to "vibe coding" or AI-generated code.
The main issue lies with Firebase, which inherently allows easy misconfigurations, leading to widespread vulnerabilities.
A single vulnerability has led to over 900 Firebase site breaches and 125 million accounts impacted, indicating systemic problems.
Firebase's design eliminates a traditional API layer, letting users directly query the database, making it easy to inadvertently expose masses of data.
Unlike traditional architecture where a backend API acts as an intermediary, Firebase often exposes everything unless explicitly restricted, making security lapses more likely.
Permission and access control become complex and error-prone since they're bolted onto the database rather than inherent to an API’s coded logic.
Many apps using Firebase have faced similar incidents due to these architectural flaws.
Traditional backend/API designs enforce security checks and only expose necessary data, while Firebase simplifies this at the cost of default overexposure.
Good practice is to write server-side code (endpoints, functions) that control data exposure and verify user identity and intent at each step.
Exposing all data by default, and retrofitting access control later, leads to repeated security failures.
Platforms like Convex enforce access through developer-defined APIs and queries, leading to more secure and deliberate data access patterns.
Proper systems require building endpoints/functions through which all database access occurs, ensuring security logic is visible and maintainable in source code.
Storing files and managing URLs through backend logic and securely exposing data prevents mass scraping and leaks.
Critique of the Development Culture and Firebase 19:29
Mobile developers often avoid learning backend/server concepts, contributing to architectural mistakes and security lapses.
Firebase, by eliminating backend knowledge requirements, appeals to such developers but creates systemic risk.
Many high-profile leaks, including those affecting large fast-food chains, stem from similar mistakes involving Firebase.
Tools like Firepone have exploited mass misconfigurations in Firebase to scrape sensitive data on a large scale.