Firebase allow read, write: if true 설명: 무엇을 하며 어떻게 고치는가

줄별 구문

완전한 Firestore 테스트 모드 규칙 문서는 6줄입니다:

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

디코딩:

• rules_version = '2';는 v2 규칙 엔진(현재)을 선택합니다. 이전 v1 규칙은 더 이상 사용되지 않습니다.
• service cloud.firestore는 블록을 Firestore로 범위 좁힙니다. Realtime Database는 다른 JSON 기반 구문을 사용합니다. Cloud Storage는 service firebase.storage를 사용합니다.
• match /databases/{database}/documents는 특별한 (default) 데이터베이스를 바인딩합니다(대부분의 프로젝트는 하나뿐입니다).
• match /{document=**}는 재귀적 와일드카드입니다. **는 모든 깊이의 모든 경로와 일치합니다. {document}와 결합하여 모든 컬렉션의 모든 문서를 캡처합니다 — 전체 데이터베이스를 지배하는 단일 match 절.
• allow read, write: if true;는 규칙 본문입니다. read와 write 모두 허용되며, 조건 if true는, 글쎄, 항상 참입니다. read는 get과 list 작업을 포함하고, write는 create, update, delete를 포함합니다.

순효과: Firebase 프로젝트 ID와 올바른 SDK를 가진 모든 클라이언트가 모든 컬렉션의 모든 문서를 읽거나 쓸 수 있습니다. 인증이 필요하지 않습니다. 속도 제한이 적용되지 않습니다.

Firebase가 왜 이를 기본으로 제공하는가

Firebase는 프로젝트를 생성한 후 처음 30초 안에 코딩을 하길 원합니다. 대안 — 읽기나 쓰기가 작동하기 전에 올바른 규칙을 작성하도록 만드는 것 — 은 온보딩을 차단할 것입니다. 그래서 Console은 데이터베이스를 생성할 때 두 가지 옵션을 제공합니다: Production mode(모든 것을 거부, 당신이 규칙을 작성) 또는 Test mode(30일 동안 모든 것 허용). 대부분의 개발자는 테스트 모드를 클릭하고 다시 방문하는 것을 잊습니다. 이전 프로젝트는 30일 타이머가 있었고, 현재 프로젝트는 자동 만료 없는 무기한 if true 규칙이 있습니다.

구조적 문제: AI 코딩 도구는 테스트 모드 규칙을 보여주는 문서, 튜토리얼, Stack Overflow 답변에서 훈련됩니다. Cursor나 Claude Code에 "Firebase를 설정하는 방법"을 물으면 답은 종종 마치 프로덕션 규칙인 것처럼 정확한 allow read, write: if true 블록을 포함합니다. AI는 알지 못하며 — 알도록 안내받지 않습니다 — 이 규칙이 프로덕션에 안전하지 않다는 것을.

공격자가 보는 것

Concretely, an attacker who knows your Firebase project ID (it ships in every deployed app's configuration) can list every collection and read every document with plain, unauthenticated requests to Firebase's public REST API.

Once the collections are listed, every document in them can be read. Nothing slows this down, because if true rules accept anonymous traffic.

쓰기 경로에서: {fields}가 있는 단일 POST가 새 문서를 만듭니다. 공격자는 컬렉션을 쓰레기로 오염시키고, Firestore에서 읽는 사용자 대면 페이지를 훼손하거나, 무료 메시지 브로커로 데이터베이스를 사용할 수 있습니다 — 사용량 청구서가 치솟고, 조사하면 청구서가 문제를 설명합니다.

네 가지 프로덕션 안전 교체

앱의 데이터 모델과 일치하는 교체를 선택하세요. 네 가지 모두 사용자 인증(Firebase Auth 또는 Firebase ID 토큰을 발급하는 모든 공급자)이 있다고 가정합니다:

옵션 1: 사용자 소유 문서

가장 흔한 SaaS 패턴. 문서는 /users/{userId}/... 하위에 있으며 소유자만 접근할 수 있습니다. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

옵션 2: 각 문서의 소유자 필드

문서가 평평한 컬렉션에 있을 때(사용자 ID 하위에 중첩되지 않음) owner_uid 필드를 저장하고 이를 확인합니다. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

옵션 3: 멀티 테넌트 조직 격리

조직 범위 데이터가 있는 B2B SaaS용. 모든 문서에 org_id 필드를 저장하고 사용자의 사용자 정의 클레임과 대조하여 확인합니다. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Firebase Admin SDK를 통해 가입 중에 사용자 정의 클레임을 설정해야 합니다.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

옵션 4: 읽기 전용 공개 콘텐츠

마케팅 콘텐츠, 공개 프로필, 제품 카탈로그용 — 진정으로 공개 읽기이지만 관리자만 쓰는 모든 것. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin 사용자 정의 클레임은 관리자 계정에만 설정됩니다.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

빠른 감사 쿼리

수정 전에 if true가 실제로 활성화되어 있는지 확인하세요. Firebase Console → Firestore → Rules를 열고 if true를 검색하세요. 주석 외부 어디에서든 발견하면 열린 규칙 발견입니다. 동일한 UI의 규칙 시뮬레이터를 사용하면 공격자의 요청을 로컬에서 재생할 수 있습니다 — 익명 GET /users/somebody를 붙여넣고 시뮬레이터가 Allowed를 반환하는지 확인하세요.

External confirmation: run a FixVibe scan against your production URL. FixVibe checks your Firestore, Realtime Database, and Storage rules from the outside and reports what an attacker would find — independent of what the Firebase Console shows.

자주 묻는 질문

다음 단계

Run a FixVibe scan against your production URL — it confirms whether if true is currently exploitable from the public internet. For how the scanner covers Realtime Database and Storage as well, see Firebase rules scanner. For the equivalent class of misconfiguration on Supabase, read Supabase RLS scanner.