Original source: https://flowpatrol.ai/blog/quittr-firebase-600k-confessions

600,000 confessions from a quit-porn app. Firebase stored them all behind 'allow read, write: if true'

This is a case of tremendous revenue earned through vibe coding, followed by spectacular failure.

The issue is not really vibe coding itself—it should have been carefully reviewed before product launch—but it serves as a warning about what can happen when someone without much programming knowledge builds a product using vibe coding.

Even professional programmers can overlook this type of issue, so I'm sharing this content to raise awareness.

It's truly shocking. What happens to the people whose data was exposed... there really seems to be no answer.

600,000 confessions. 100,000 minors. One Firebase rule.

In March 2026, when 404 Media reported its investigation findings, the numbers revealed were as follows: approximately 600,000 exposed user records. About 100,000 of them contained data from minors. It was not just email addresses or usernames. The records included user-reported masturbation frequency, emotional triggers, content categories, and free-text personal confessions—the most private information on consumer internet—linked with verified age information.

The cause was a single Firebase rule: allow read, write: if true.

It was the default setting configured on the day the project was created and was never changed again.

Below, we examine what Quittr actually collected from new users before creating a "customized recovery plan": age. Pornography viewing frequency. Masturbation frequency. Triggers that stimulate users—stress, boredom, loneliness, specific emotional situations. Content categories the user wants to quit. And a free-text input field: Why do you want to quit?

There are data breach cases where sensitivity matters more than volume. This is exactly such a case. Email addresses are merely an inconvenience. But user-reported masturbation frequency, personal confessions, and email addresses linked with verified age information including minors become compounded risk factors that can lead to long-term harassment, sextortion, and doxxing.

The Application That Collected This Data

The reason this story resonates so painfully is that Quittr's case reads like a recruitment poster for "vibe coding."

• Built by 19-year-old Alex Slater and co-founder Connor. First startup experience. No security background.

• Launched in about 10 days. Client in SwiftUI, backend in Firebase, paywall implementation using Superwall.

• Over 350,000 downloads in 6 months, used in 120 countries, monthly recurring revenue (MRR) of approximately $250,000, total revenue exceeding $1.1 million—bootstrap approach, no venture capital.

• Featured in Dazed, The Week, Oprah Winfrey's Facebook post, L.A. Weekly, and others. One of the most cited examples of "app mafia"—young founders launching six-figure MRR consumer apps without large stacks and teams.

Ship fast. Stay small. Capture revenue. Skip venture capital. These are all headlines developers want to read. Nobody in this story did something wrong simply because they built fast. The tools they used to build provided production-inappropriate defaults, and nobody told them.

Firebase's allow read, write: if true rule created an open door between Quittr's sensitive data (age, habits, confessions, information about 100,000 minors) and anyone on the internet.

The Rule

When selecting "Test Mode" during project creation, Firebase provides the following rule by default:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

if true means exactly what it says. Read anything. Write anything. No authentication required. No ownership verification required. No rate limiting. Your users, your data, your confessions—accessible via a single HTTPS request from a laptop on the other side of the world.

Quittr's Firebase project operated in exactly this state. Not because someone made a mistake. Because this is the option Firebase provides when creating a new project, and from that moment until production deployment, there is no mechanism telling you that this setting is wrong.

Security researcher Kaeden summarized the vulnerability in a public message about Quittr cited by 404 Media as follows:

Your Firebase (database) configuration is misconfigured allowing read/write access to anything. For example, you can list all users and their information, which is a pretty serious issue for an app of this nature.

"Pretty serious issue for an app of this nature" is the understatement of the year. But Kaeden's report is technically simple because the vulnerability itself is technically simple. Nothing to connect, nothing to exploit, no zero-day to reverse-engineer. The rule says if true, and the database said "yes."

Why This Is Not Just Quittr's Story

Quittr is the fourth major Firebase-based consumer application to experience this exact failure mode in the past 12 months. Cases where the identical allow read, write: if true default was deployed to production:

Four apps. Four completely independent teams. Four different data categories. One rule. The rule Firebase provides by default when clicking "Test Mode" on day one.

The pattern here is important: if four different teams—including a 19-year-old founder who built a $1 million app in 10 days and a calorie-tracking startup with 3.2 million users—all deployed the same bug to production, the bug is not with the developers. The bug is the default.

Three Factors That Let Defaults Survive

Quittr's founders built the app in about 10 days. The Firebase rules file was probably set once at project creation and never reviewed again. This is not carelessness. This is a phenomenon where development-stage defaults survive into production due to three specific characteristics of Firebase architecture.

1. The rules surface. When building a SwiftUI app and reading users from Firebase, every read request returns data. Every write request succeeds. From the backend's perspective, there is no runtime signal distinguishing the app's happy path from an attacker's happy path. "The app works" and "the database is open to the internet" are the same observation.

2. Rules exist in a different tab. Firebase Console provides the database, authentication, storage, and rules as separate sections. You can complete the entire process of building, testing, and deploying an app without ever opening the Rules tab. The IDE doesn't show the rules file. The build system doesn't check it. Neither does the AI scaffolder.

3. There is no deployment gate. Firebase will happily deploy allow read, write: if true to production. No build-time checks. No warning email before deployment. No reviewer. The same "Deploy" button that deploys securely locked rules also deploys test-mode rules. As of 2026, after millions of records exposed across thousands of projects, the firebase deploy command still does not have a --i-know-this-is-test-mode flag.

This is a gap no AI code generator can fill. Every LLM scaffolder is trained to generate working code. On Firebase, "working code" means code that reads and writes without permission errors. The fastest way to get there is to leave test mode on. The rules file doesn't show up in the IDE, doesn't break the build, doesn't trigger errors. The scaffolder deploys "the working thing." And "the working thing" is open.

Disclosure

Between July 2025, August, and beyond, three independent security researchers contacted Quittr about the open database. The first researcher, Kaeden, reportedly received a response saying the fix would be deployed within an hour. However, the rule remained unchanged for approximately 8 months and was only fixed after 404 Media requested comment and published its findings on March 10-11, 2026.

This gap should be understood not as a judgment of the founders, but as evidence that most "vibe coding" projects lack disclosure infrastructure: no security.txt file. No security@ email alias. No triage process. When a 19-year-old founder has never opened the Firebase Rules tab and a report arrives via Twitter direct message, the natural failure mode is to defer it behind the next feature release—not because the founder doesn't care, but because fixing it requires navigating an unfamiliar interface without visible pressure to do so. The app still works. Revenue still grows. The Rules tab is still right where it's always been.

This is a solvable problem. A security@ alias costs nothing. A written triage rule stating "security reports receive a commit, not a response, within 24 hours" costs nothing. Adding these before launch is the difference between same-day fixes and eight months of exposure ending with a journalist in your inbox.

5-Minute Audit

If you're deploying an app through Firebase, run the following checks on your app today. It costs nothing and takes less time than reading this article.

1. Open Firebase Console → Firestore Database → Rules. Search for if true. If it appears at the root level, you have test mode deployed to production. This is the Quittr bug. Fix it before anything else.

2. Check each Firebase product separately. Realtime Database, Firestore, and Storage are three separate products, each with separate rules files. Tea's breach was Storage, Quittr was the database, Cal AI was Firestore. Securing one doesn't secure the others. Open each tab. Read each file.

3. Test from an unauthenticated client. While not logged in, curl a REST endpoint for one of your collections. If data is returned, your rules are wrong.

4. Write rules that default to deny:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }

    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Start from if false. Open only what you decide to expose. Never start from if true and add restrictions.

5. Add a public inbox today. A security@yourapp.com alias. A /security.txt file. One paragraph explaining how to report issues. Zero cost. Without this, same-day fixes become eight months of exposure, which eventually becomes a journalist in your inbox.

How Flowpatrol Detects This

Quittr's breach was one Firebase rule. The entire exploit path—credential extraction, unauthenticated queries, full data dump—completes in under 60 seconds. Our scanner automatically walks this exact chain:

$ flowpatrol scan https://quittr.app
Scanning... 4 endpoints discovered

✗ Critical: Firebase Firestore — unauthenticated read access
  Rule: allow read, write: if true (test-mode default)
  Collections readable: users, confessions, streaks, plans
  Records returned without auth: 600,000+

✗ Critical: Firebase credentials exposed in client bundle
  Project ID: quittr-xxxxx
  API key: AIzaSy...

✗ High: No security.txt or disclosure endpoint

Done in 2m 34s — 3 findings, 2 critical

We extract Firebase and Supabase credentials from the client bundle, test all discoverable collections using the anon key, and flag anything returning data it shouldn't. The check that detects the Quittr bug is the same check that detected the same bug in Cal AI, Tea, and 916 other Firebase projects. Five minutes. One URL.

Quittr was an excellent app, built at exceptional speed by a founder the internet cheered. The data it collected was among the most sensitive on consumer internet. And the rule that exposed it was a default.

The app was impressive. The default was not. Fix the default.

This case study is based on public reporting from 404 Media (March 10-11, 2026), Cybernews, Techlicious, DataBreaches.net, and founder interviews including BoringCashCow and L.A. Weekly. Reported exposure figures (600,000 users, approximately 100,000 minors, eight months of public exposure) are as documented in 404 Media's two-part investigation.