Sumber Asli : https://flowpatrol.ai/blog/quittr-firebase-600k-confessions

600.000 pengakuan dari aplikasi berhenti-porno. Firebase menyimpan semuanya di balik 'allow read, write: if true'

Ini adalah kasus di mana seseorang mendapat pendapatan besar dari coding vibe tetapi kemudian mengalami kegagalan spektakuler.

Sebenarnya, masalahnya bukan pada vibe coding, tetapi seharusnya ada pemeriksaan menyeluruh sebelum meluncurkan produk dengan vibe coding. Namun, ini berfungsi sebagai peringatan tentang apa yang dapat terjadi ketika seseorang tanpa banyak pengetahuan pemrograman membuat produk menggunakan vibe coding.

Bahkan programmer profesional dapat melewatkan hal seperti ini, jadi saya memposting konten terkait untuk meningkatkan kesadaran.

Ini sangat mengejutkan. Saya tidak tahu apa yang akan terjadi pada orang-orang yang datanya terbocor... Saya benar-benar tidak melihat jalannya keluar.

600.000 pengakuan. 100.000 anak di bawah umur. Satu aturan Firebase.

Pada Maret 2026, ketika 404 Media melaporkan temuan mereka, angka-angkanya berbicara sendiri: sekitar 600.000 catatan pengguna terbuka. Dari jumlah tersebut, sekitar 100.000 adalah data anak di bawah umur. Bukan hanya alamat email atau nama pengguna. Catatan tersebut berisi frekuensi masturbasi yang dilaporkan pengguna sendiri, pemicu emosional, kategori konten, dan pengakuan pribadi dalam bentuk teks bebas — informasi paling pribadi yang ditangani oleh internet konsumen, semuanya terhubung dengan verifikasi usia resmi.

Penyebabnya adalah satu aturan Firebase: allow read, write: if true.

Ini adalah pengaturan default saat proyek dibuat, dan tidak pernah diubah sejak saat itu.

Di bawah ini, kami akan melihat apa yang sebenarnya dikumpulkan Quittr dari pengguna baru sebelum membuat "rencana pemulihan yang dipersonalisasi": usia. Frekuensi menonton pornografi. Frekuensi masturbasi. Pemicu yang memengaruhi pengguna — stres, kebosanan, kesepian, situasi emosional tertentu. Kategori konten yang ingin dihentikan oleh pengguna. Dan bidang input teks bebas: Mengapa Anda ingin berhenti?

Ada jenis kebocoran data di mana sensitivitas lebih penting daripada volume. Ini adalah salah satunya. Alamat email adalah masalah yang mengganggu. Tetapi alamat email yang terhubung dengan frekuensi masturbasi yang dilaporkan pengguna sendiri, pengakuan pribadi, dan verifikasi usia untuk termasuk anak di bawah umur menciptakan vektor risiko majemuk yang dapat memicu pelecehan jangka panjang, sextortion, dan doxing.

Aplikasi yang Mengumpulkan Data Ini

Kisah ini terasa lebih menyakitkan karena kasus Quittr terasa seperti posting lowongan pekerjaan untuk "vibe coding".

• Dibangun oleh Alex Slater (19 tahun) dan co-founder Conner. Pengalaman startup pertama. Tanpa latar belakang keamanan.

• Diluncurkan dalam sekitar 10 hari. Client SwiftUI, backend Firebase, menggunakan Superwall untuk implementasi paywall.

• Lebih dari 350.000 download dalam 6 bulan, digunakan di 120 negara, MRR sekitar $250.000, total revenue melebihi $1.100.000 — bootstrap, tanpa investasi venture capital.

• Ditampilkan di Dazed, The Week, posting Facebook Oprah Winfrey, L.A. Weekly, dan lainnya. Salah satu contoh "app mafia" paling sering dikutip dari entrepreneur muda yang meluncurkan aplikasi konsumen dengan MRR 7 angka dengan stack kecil dan tim tanpa VC.

Bangun cepat. Pertahankan skala kecil. Kuasai pendapatan. Lewati venture capital. Ini semua adalah headline yang ingin dibaca developer. Tidak ada orang dalam cerita ini yang melakukan sesuatu yang salah hanya karena mereka membangun dengan cepat. Alat yang mereka gunakan untuk membangun menyediakan default yang tidak cocok untuk production, dan tidak ada yang memberitahu mereka.

Aturan Firebase allow read, write: if true menciptakan pintu terbuka antara data sensitif yang dikumpulkan Quittr — usia, kebiasaan, pengakuan, data 100.000 anak di bawah umur — dan siapa saja di internet.

Aturan Itu

Ketika membuat proyek dan memilih "mode test", Firebase menyediakan aturan default berikut:

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

if true berarti persis apa yang tertulis. Anda dapat membaca apa saja. Anda dapat menulis apa saja. Tidak ada autentikasi. Tidak ada verifikasi kepemilikan. Tidak ada batasan tingkat. Pengguna Anda, data Anda, pengakuan Anda — semuanya dapat diakses oleh satu laptop di sisi lain dunia dengan satu permintaan HTTPS saja.

Proyek Firebase Quittr beroperasi dalam kondisi ini. Bukan karena seseorang membuat kesalahan. Karena ini adalah opsi yang disediakan Firebase saat membuat proyek baru, dan tidak ada mekanisme yang memberi tahu bahwa pengaturan ini salah dari saat itu hingga deployment production.

Peneliti keamanan Kaeden merangkum kerentanan dalam pesan publik kepada Quittr yang kemudian dikutip oleh 404 Media:

Konfigurasi Firebase (database) Anda salah, memungkinkan siapa saja untuk membaca/menulis apa saja. Misalnya, Anda dapat membuat daftar semua pengguna dan informasi mereka, yang merupakan masalah yang cukup parah untuk aplikasi jenis ini.

Frasa "masalah yang cukup parah untuk aplikasi jenis ini" adalah understatement terbesar tahun ini. Tetapi laporan Kaeden secara teknis sederhana — karena kerentanan itu sendiri sederhana secara teknis. Tidak ada koneksi yang rumit, tidak ada yang perlu dieksploitasi, tidak ada zero-day untuk dibalikkan. Aturan mengatakan if true, dan database menjawab "ya".

Mengapa Ini Bukan Hanya Cerita Quittr

Quittr adalah aplikasi konsumen berbasis Firebase keempat yang mengalami mode kegagalan yang persis sama dalam 12 bulan terakhir. Kasus-kasus di mana default allow read, write: if true yang sama telah di-deploy ke production adalah:

Empat aplikasi. Empat tim yang sepenuhnya independen. Empat kategori data yang berbeda. Satu aturan. Aturan yang disediakan Firebase secara default ketika Anda mengklik "mode test" pada hari pertama.

Yang penting di sini adalah polanya: ketika empat tim independen — termasuk entrepreneur 19 tahun yang membangun aplikasi senilai $1.000.000 dalam 10 hari dan startup pelacakan kalori dengan 3,2 juta pengguna — semuanya men-deploy bug yang sama ke production, bug itu bukan pada developer. Bug itu adalah default.

Tiga Faktor yang Membuat Default Bertahan

Founder Quittr membangun aplikasi dalam sekitar 10 hari. File aturan Firebase mungkin diatur sekali saat pembuatan proyek, dan tidak pernah ditinjau ulang. Ini bukan kelalaian. Ini adalah fenomena di mana default dari tahap pengembangan bertahan hingga production karena tiga karakteristik spesifik dari arsitektur Firebase.

1. Permukaan aturan. Ketika Anda membangun aplikasi SwiftUI dan membaca pengguna dari Firebase, setiap permintaan baca mengembalikan data. Setiap permintaan tulis berhasil. Dari perspektif backend, tidak ada sinyal runtime yang membedakan jalur bahagia aplikasi Anda dari jalur bahagia penyerang. "Aplikasi bekerja" dan "database terbuka ke internet" adalah pengamatan yang sama.

2. Aturan ada di tab lain. Konsol Firebase memberikan database, autentikasi, penyimpanan, dan aturan di bagian terpisah. Anda dapat menyelesaikan seluruh proses membangun, menguji, dan men-deploy aplikasi tanpa pernah membuka tab Rules. IDE tidak menampilkan file aturan. Sistem build tidak memeriksanya. Scaffolder AI juga tidak.

3. Tidak ada pemicu deployment. Firebase dengan senang hati men-deploy allow read, write: if true ke production. Tidak ada pemeriksaan pada waktu build. Tidak ada email peringatan sebelum deployment. Tidak ada reviewer. Tombol "Deploy" yang sama yang men-deploy aturan yang aman dengan kunci juga men-deploy aturan mode test. Pada tahun 2026, setelah jutaan record bocor dari ribuan proyek, perintah firebase deploy masih tidak memiliki flag --i-know-this-is-test-mode.

Ini adalah celah yang tidak bisa diisi oleh generator kode AI. Setiap scaffolder LLM dilatih untuk menghasilkan kode yang berfungsi. Pada Firebase, "kode yang berfungsi" berarti kode yang dapat membaca dan menulis tanpa kesalahan permission. Cara tercepat untuk mencapai itu adalah membiarkan mode test tetap aktif. File aturan tidak muncul di IDE, tidak memecahkan build, tidak memicu kesalahan. Scaffolder men-deploy "apa yang berfungsi". Dan "apa yang berfungsi" adalah apa yang terbuka.

Pengungkapan

Sepanjang Juli, Agustus, dan seterusnya pada tahun 2025, tiga peneliti keamanan independen menghubungi Quittr tentang database yang terbuka. Kaeden, peneliti pertama, dilaporkan menerima jawaban bahwa perbaikan akan di-deploy dalam waktu satu jam. Namun, aturan tetap tidak berubah selama sekitar 8 bulan, dan hanya diperbaiki setelah 404 Media meminta komentar dan melaporkan temuan mereka pada 10-11 Maret 2026.

Celah ini kurang merupakan penilaian terhadap founder daripada cerminan dari fakta bahwa sebagian besar proyek "vibe coding" kekurangan infrastruktur pengungkapan — tidak ada file security.txt, tidak ada alias email security@, tidak ada proses triage. Ketika laporan datang melalui DM Twitter kepada entrepreneur 19 tahun yang tidak pernah membuka tab Firebase Rules, mode kegagalan alami adalah menundanya di belakang rilis fitur berikutnya — bukan karena founder tidak peduli, tetapi karena memperbaikinya memerlukan navigasi antarmuka yang asing tanpa tekanan yang terlihat. Aplikasi masih bekerja. Pendapatan masih tumbuh. Tab Rules masih di tempat yang sama seperti biasanya.

Ini adalah masalah yang dapat diselesaikan. Alias security@ tidak ada biayanya. Aturan triage tertulis yang mengatakan "laporan keamanan menerima commit dalam 24 jam, bukan balasan" tidak ada biayanya. Menambahkannya sebelum launch adalah perbedaan antara perbaikan hari yang sama dan 8 bulan sebelum jurnalis sampai di kotak masuk Anda.

Audit 5 Menit

Jika Anda men-deploy aplikasi melalui Firebase, lakukan audit cepat berikut pada aplikasi Anda hari ini. Ini tidak ada biayanya dan akan selesai lebih cepat daripada membaca artikel ini.

1. Buka Firebase Console → Firestore Database → Rules. Cari if true. Jika muncul di root level, Anda memiliki mode test di production. Ini adalah bug Quittr. Perbaiki ini sebelum apa pun.

2. Periksa setiap produk Firebase secara terpisah. Realtime Database, Firestore, dan Storage adalah tiga produk terpisah dengan file aturan terpisah. Kebocoran Tea adalah Storage, Quittr adalah database, Cal AI adalah Firestore. Mengamankan satu tidak mengamankan yang lain. Buka setiap tab, baca setiap file.

3. Uji dari klien yang tidak terautentikasi. Curl endpoint REST untuk salah satu koleksi tanpa login. Jika data dikembalikan, aturan Anda salah.

4. Tulis aturan yang menggunakan deny-by-default:

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;
    }
  }
}

Mulai dengan if false. Buka hanya apa yang Anda tentukan untuk expose. Jangan pernah mulai dengan if true dan tambahkan pembatasan.

5. Tambahkan inbox publik hari ini. Alias security@yourapp.com. File /security.txt. Satu paragraf yang menjelaskan cara melaporkan masalah. Biayanya nol. Tanpa ini, perbaikan hari yang sama menjadi 8 bulan lamanya, dan jurnalis akhirnya sampai ke kotak masuk Anda.

Bagaimana Flowpatrol Mendeteksi Ini

Kebocoran Quittr adalah satu aturan Firebase. Seluruh jalur eksploitasi — ekstraksi kredensial, query tanpa autentikasi, dump data penuh — selesai dalam 60 detik. Scanner kami secara otomatis menelusuri rantai yang sama persis:

$ 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

Kami mengekstrak kredensial Firebase dan Supabase dari bundle klien, menguji setiap koleksi yang dapat ditemukan menggunakan anon key, dan menandai apa pun yang mengembalikan data yang tidak seharusnya. Pemeriksaan untuk mendeteksi bug Quittr adalah pemeriksaan yang sama yang mendeteksi bug di Cal AI, Tea, dan 916 proyek Firebase lainnya. Lima menit. Satu URL.

Quittr adalah aplikasi yang luar biasa, dibangun oleh entrepreneur yang dikagumi oleh internet dengan kecepatan yang luar biasa. Data yang dikumpulkan oleh aplikasi itu termasuk dalam kategori paling sensitif yang ditangani oleh internet konsumen. Dan aturan yang mengekspos data itu adalah default.

Aplikasinya mengesankan. Defaultnya tidak. Perbaiki default-nya.

Studi kasus ini didasarkan pada liputan publik dari 404 Media (10-11 Maret 2026), Cybernews, Techlicious, DataBreaches.net, dan wawancara founder di BoringCashCow dan L.A. Weekly. Angka kebocoran yang dilaporkan — 600.000 pengguna, sekitar 100.000 anak di bawah umur, 8 bulan exposur terbuka — didokumentasikan seperti yang ada dalam investigasi dua bagian 404 Media.