원본 출처 : 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'

바이브 코딩으로 엄청난 수익을 얻었다가 폭망한 사례입니다.

사실 바이브 코딩이 문제가 아니고 바이브 코딩으로 제품을 출시하기 전 꼼꼼하게 살폈어야 했지만 프로그래밍 지식이 별로 없는 사람이 바이브 코딩으로 제품을 만들면 어떤 일이 벌어질 수 있는지에 대한 경고라고 보여져요.

이는 전문 프로그래머라고 해도 깜빡 하고 놓칠 수 있는 부분이기도 해서 경각심에 관련 내용을 올려봅니다.

너무 충격적이네요. 유출된 사람들은 어떻게 되는건지... 대체 답이 안보이네요.

60만 건의 고백. 10만 명의 미성년자. 단 하나의 Firebase 규칙.

2026 년 3 월, 404 Media 가 조사 결과를 보도했을 때 드러난 수치는 다음과 같았습니다: 노출된 사용자 기록 약 60 만 건. 그중 약 10 만 건이 미성년자의 데이터였습니다. 단순한 이메일 주소도, 사용자 아이디도 아니었습니다. 해당 기록에는 사용자가 직접 보고한 자위 빈도, 감정적 유발 요인, 콘텐츠 카테고리, 그리고 자유 텍스트 형식의 개인적 고백 — 소비자 인터넷이 다루는 데이터 중 가장 사적인 정보들이, 검증된 연령 정보와 연계된 채 포함되어 있었습니다.

원인은 단 하나의 Firebase 규칙이었습니다: allow read, write: if true.

프로젝트 생성 당일에 설정된 기본값이었으며, 이후 단 한 번도 변경되지 않았습니다.

이하에서 Quittr 이 새 사용자로부터 "맞춤형 회복 계획"을 생성하기 전에 실제로 수집하는 항목들을 살펴보겠습니다: 연령. 포르노 시청 빈도. 자위 빈도. 사용자를 자극하는 유발 요인 — 스트레스, 지루함, 외로움, 특정 감정적 상황. 사용자가 끊으려 하는 콘텐츠 카테고리. 그리고 자유 텍스트 입력란: 왜 끊고 싶으신가요?

데이터의 양보다 민감도가 더 중요한 유형의 데이터 유출 사례가 존재합니다. 이번 사례가 바로 그렇습니다. 이메일 주소는 귀찮은 문제일 뿐입니다. 하지만 사용자 스스로 보고한 자위 빈도, 개인적 고백, 그리고 미성년자를 포함한 검증된 연령 정보와 연계된 이메일 주소는 장기적인 괴롭힘, 섹스토션 (성적 협박), 그리고 독싱 (개인정보 노출) 을 유발할 수 있는 복합적 위험 요소가 됩니다.

해당 데이터를 수집한 애플리케이션

이 이야기가 더욱 뼈아프게 다가오는 이유는, Quittr 의 사례가 마치 "바이브 코딩 (vibe coding)"을 위한 채용 포스터처럼 읽히기 때문입니다.

• 19 세의 알렉스 슬레이터 (Alex Slater)와 공동 창업자 코너가 구축. 첫 창업 경험. 보안 관련 배경지식 없음.

• 약 10 일 만에 출시. 클라이언트는 SwiftUI, 백엔드는 Firebase, 결제 장벽 (paywall) 구현에는 Superwall 사용.

• 6 개월 만에 35 만 건 이상 다운로드, 120 개국에서 사용, 월간 반복 매출 (MRR) 약 25 만 달러, 총 매출 110 만 달러 초과 — 부트스트랩 방식, 벤처캐피탈 투자 없음.

• Dazed, The Week, 오프라 윈프리의 페이스북 게시물, L.A. Weekly 등에 소개. 소규모 스택과 팀 없이 6 자리 수 MRR 소비자 앱을 출시하는 젊은 창업자들의 "앱 마피아" 사례 중 가장 많이 인용된 사례 중 하나.

빠르게 출시하라. 소규모로 유지하라. 수익을 장악하라. 벤처캐피탈은 건너뛰라. 이 모든 사실은 개발자가 읽고 싶어 하는 헤드라인입니다. 이 이야기 속 그 누구도 빠르게 구축했다는 이유만으로 잘못된 일을 한 것은 아닙니다. 그들이 구축에 사용한 도구가 프로덕션 환경에는 적합하지 않은 기본값을 제공했고, 그 사실을 아무도 알려주지 않았습니다.

Firebase 의 allow read, write: if true 규칙은 Quittr 이 수집한 민감한 데이터 (연령, 습관, 고백, 10 만 명의 미성년자 정보) 와 인터넷 상의 누구 사이에도 열린 문을 만들어냈습니다.

그 규칙

프로젝트 생성 시 "테스트 모드"를 선택하면 Firebase 는 다음과 같은 규칙을 기본으로 제공합니다:

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

if true 는 말 그대로의 의미를 지닙니다. 무엇이든 읽을 수 있습니다. 무엇이든 쓸 수 있습니다. 인증 불필요. 소유권 확인 불필요. 속도 제한 불필요. 여러분의 사용자, 여러분의 데이터, 여러분의 고백 — 지구 반대편에 있는 노트북 하나가 단일 HTTPS 요청만으로 접근할 수 있는 상태가 됩니다.

Quittr 의 Firebase 프로젝트가 바로 이 상태로 운영되고 있었습니다. 누군가 실수를 해서가 아닙니다. 이것이 Firebase 가 새 프로젝트 생성 시 제공하는 옵션이기 때문이며, 그 순간부터 프로덕션 배포 시점까지 그 설정이 잘못되었다고 알려주는 어떠한 장치도 존재하지 않기 때문입니다.

보안 연구자 Kaeden 은 404 Media 가 이후 인용한 Quittr 에 대한 공개 메시지 에서 해당 취약점을 다음과 같이 요약했습니다:

귀하의 Firebase(데이터베이스) 설정이 잘못되어 있어 무엇이든 읽기/쓰기가 가능합니다. 예를 들어, 모든 사용자와 그들의 정보를 나열할 수 있는데, 이는 이러한 성격의 앱에서는 상당히 심각한 문제입니다.

"이러한 성격의 앱에서는 상당히 심각한 문제"라는 표현은 올해의 과소평가 표현상감입니다. 하지만 Kaeden 의 보고서는 기술적으로 단순합니다. 왜냐하면 해당 취약점 자체가 기술적으로 단순하기 때문입니다. 연결할 것도, 악용할 것도, 역분석할 제로데이 취약점도 없습니다. 규칙이 if true라고 명시했고, 데이터베이스는 "예"라고 응답했을 뿐입니다.

이것이 단순히 Quittr 만의 이야기가 아닌 이유

Quittr 은 지난 12 개월 동안 정확히 동일한 실패 모드를 겪은 네 번째 주요 Firebase 기반 소비자 애플리케이션입니다. 동일한 allow read, write: if true 기본값이 프로덕션 환경에 배포된 사례는 다음과 같습니다:

네 개의 앱. 네 개의 완전히 독립적인 팀. 네 가지 다른 데이터 카테고리. 단 하나의 규칙. Firebase 가 첫날 "테스트 모드"를 클릭할 때 기본적으로 제공하는 그 규칙입니다.

여기서 중요한 것은 패턴입니다: 19 세의 창업자가 10 일 만에 100 만 달러 규모의 앱을 구축한 사례와 320 만 사용자를 보유한 칼로리 추적 스타트업을 포함해, 네 개의 서로 다른 팀이 모두 동일한 버그를 프로덕션에 배포했다면, 버그는 개발자에게 있는 것이 아닙니다. 버그는 기본값 (default)

기본값이 살아남게 만드는 세 가지 요소

Quittr 의 창업자는 약 10 일 만에 앱을 구축했습니다. Firebase 규칙 파일은 아마도 프로젝트 생성 시 한 번 설정된 후, 이후 단 한 번도 재검토되지 않았을 것입니다. 이는 부주의함이 아닙니다. 이는 Firebase 아키텍처의 세 가지 구체적인 특성으로 인해, 개발 단계의 기본값이 프로덕션 환경까지 도전받지 않고 유지되는 현상입니다.

1. 규칙 표면 (rules surface) SwiftUI 앱을 구축하고 Firebase 에서 사용자를 읽어올 때, 모든 읽기 요청은 데이터를 반환합니다. 모든 쓰기 요청은 성공합니다. 백엔드가 다른 모든 사람에게도 읽히는지 여부를 알려주는 런타임 신호 (runtime signal) 서버의 관점에서 볼 때, 앱의 정상 경로 (happy path) 와 공격자의 정상 경로는 구별할 수 없습니다. "앱이 작동한다"와 "데이터베이스가 인터넷에 개방되어 있다"는 동일한 관찰 결과입니다.

2. 규칙은 다른 탭에 존재합니다. Firebase 콘솔은 데이터베이스, 인증, 스토리지, 그리고 규칙을 별도의 섹션으로 제공합니다. 앱을 구축, 테스트, 배포하는 전체 과정을 Rules (규칙) 탭을 한 번도 열어보지 않고 완료할 수 있습니다. IDE 는 규칙 파일을 표시하지 않습니다. 빌드 시스템은 이를 확인하지 않습니다. AI 스캐폴더 (scaffolder) 역시 마찬가지입니다.

3. 배포 차단 장치가 없습니다. Firebase 는 allow read, write: if true를 프로덕션 환경에 기꺼이 배포합니다. 빌드 시점 점검 없음. 배포 전 경고 이메일 없음. 리뷰어 없음. 안전하게 잠긴 규칙을 배포하는 것과 동일한 "배포 (Deploy)" 버튼이 테스트 모드 규칙도 배포합니다. 2026 년 현재, 수천 개의 프로젝트에서 수억 건의 기록이 유출된 이후에도, firebase deploy 명령어에는 여전히 --i-know-this-is-test-mode 플래그가 존재하지 않습니다.

이는 AI 코드 생성기도 채울 수 없는 간격입니다. 모든 LLM 스캐폴더는 작동하는 코드를 생성하도록 학습되어 있습니다. Firebase 에서 "작동하는 코드"란 권한 오류 없이 읽고 쓸 수 있는 코드입니다. 이에 도달하는 가장 빠른 방법은 테스트 모드를 켜둔 채로 두는 것입니다. 규칙 파일은 IDE 에 표시되지도, 빌드를 실패시키지도, 오류를 트리거하지도 않습니다. 스캐폴더는 "작동하는 것"을 배포합니다. 그리고 "작동하는 것"은 개방된 상태입니다.

공개 **(disclosure)

2025 년 7 월, 8 월, 그리고 이후 시점에 걸쳐 세 명의 독립적인 보안 연구자가 개방된 데이터베이스와 관련해 Quittr 에 연락했습니다. 첫 번째 연구자인 Kaeden 은 reportedly (보도에 따르면) 수정 사항이 1 시간 이내에 배포될 것이라는 답변을 받았다고 합니다. 그러나 해당 규칙은 약 8 개월 동안 변경되지 않은 채 유지되었고, 2026 년 3 월 404 Media 가 논평을 요청하고 3 월 10~11 일에 조사 결과를 보도한 이후에야 수정되었습니다.

이 간격은 창업자들에 대한 판단으로서보다는, 대부분의 "바이브 코딩" 프로젝트에는 공개 인프라 (disclosure infrastructure) security.txt 파일 없음. security@ 이메일 별칭 없음. 트리아지 (우선순위 분류) 프로세스 없음. 19 세의 창업자가 단 한 번도 Firebase Rules 탭을 열어본 적이 없는 상황에서 트위터 다이렉트 메시지를 통해 보고서가 도착할 때, 자연스러운 실패 모드는 이를 다음 기능 릴리스 뒤로 미루는 것입니다 — 창업자가 신경 쓰지 않아서가 아니라, 수정을 위해 가시적인 압박 없이 낯선 인터페이스를 탐색해야 하기 때문입니다. 앱은 여전히 작동합니다. 수익은 여전히 성장하고 있습니다. Rules 탭은 여전히 항상 있던 그 자리에 있습니다.

이는 해결 가능한 문제입니다. security@ 별칭은 비용이 들지 않습니다. "보안 보고서는 답변이 아닌 24 시간 내 커밋을 받는다"는 서면 트리아지 규칙도 비용이 들지 않습니다. 출시 전에 이를 추가하는 것이, 당일 수정과 8 개월의 간격 끝에 기자가 메일함에 도착하는 상황의 차이입니다.

5 분 감사 **(audit)

Firebase 를 통해 앱을 배포 중이라면, 오늘 자신의 앱에 대해 다음 점검을 수행해 보십시오. 비용은 들지 않으며, 이 글을 읽는 데 걸리는 시간보다 짧게 완료할 수 있습니다.

1. Firebase 콘솔 → Firestore Database → Rules 를 엽니다. if true를 검색하십시오. 루트 수준에 나타난다면, 프로덕션 환경에 테스트 모드가 적용된 상태입니다. 이것이 바로 Quittr 버그입니다. 다른 어떤 작업보다 먼저 이를 수정하십시오.

2. 각 Firebase 제품을 별도로 확인하십시오. Realtime Database, Firestore, Storage 는 각각 별도의 규칙 파일을 가진 세 가지 별개의 제품입니다. Tea 의 유출 사례는 Storage 였고, Quittr 은 데이터베이스, Cal AI 는 Firestore 였습니다. 하나를 보안한다고 해서 다른 것들까지 보안되는 것은 아닙니다. 각 탭을 열고, 각 파일을 읽으십시오.

3. 인증되지 않은 클라이언트에서 테스트하십시오. 로그인하지 않은 상태에서 컬렉션 중 하나에 대한 REST 엔드포인트를 curl 로 요청하십시오. 데이터가 반환된다면 규칙이 잘못된 것입니다.

4. 기본적으로 거부를 전제로 하는 규칙을 작성하십시오:

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

  }
}

if false에서 시작하십시오. 노출하기로 결정한 항목만 열어주십시오. 결코 if true에서 시작해 제한을 추가하는 방식으로 접근하지 마십시오.

5. 오늘 공개용 수신함을 추가하십시오. security@yourapp.com 별칭. /security.txt 파일. 이슈 신고 방법을 설명하는 단락 하나. 비용은 제로입니다. 이것이 부재할 때, 당일 수정이 8 개월의 간격으로 변하고, 결국 기자의 메일이 도착하게 됩니다.

Flowpatrol 이 이를 탐지하는 방식

Quittr 의 유출 사례는 단 하나의 Firebase 규칙이었습니다. 전체 익스플로잇 경로 — 자격 증명 추출, 비인증 쿼리, 전체 데이터 덤프 — 는 60 초 이내에 완료됩니다. 당사의 스캐너는 정확히 이 체인을 자동으로 탐색합니다:

$ 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

당사는 클라이언트 번들에서 Firebase 및 Supabase 자격 증명을 추출하고, 익명 키 (anon key) 를 사용하여 발견 가능한 모든 컬렉션을 테스트하며, 허용되어서는 안 되는 데이터를 반환하는 모든 항목을 플래그 처리합니다. Quittr 버그를 탐지하는 검사는 Cal AI, Tea, 그리고 기타 916 개의 Firebase 프로젝트에서 동일한 버그를 탐지한 검사와 동일합니다. 5 분. 하나의 URL.

Quittr 은 인터넷이 찬사하는 것을 출시한 창업자에 의해, 특별한 속도로 구축된 뛰어난 앱이었습니다. 해당 앱이 수집한 데이터는 소비자 인터넷이 다루는 데이터 중 가장 민감한 부류에 속했습니다. 그리고 해당 데이터를 노출시킨 규칙은 기본값이었습니다.

앱은 인상적이었습니다. 기본값은 그렇지 않았습니다. 기본값을 수정하십시오.

본 사례 연구는 404 Media (2026 년 3 월 10~11 일), Cybernews, Techlicious, DataBreaches.net 의 공개 보도 및 BoringCashCow, L.A. Weekly 를 포함한 창업자 인터뷰를 바탕으로 작성되었습니다. 보고된 노출 수치 (600,000 명의 사용자, 약 100,000 명의 미성년자, 8 개월의 공개 간격) 는 404 Media 의 2 부작 조사에서 문서화된 바와 같습니다.