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는 알지 못하며 — 알도록 안내받지 않습니다 — 이 규칙이 프로덕션에 안전하지 않다는 것을.

공격자가 보는 것

구체적으로, 당신의 Firebase 프로젝트 ID(배포된 앱의 번들에서 30초 안에 추출 가능)를 알고 다음을 실행하는 공격자는 모든 컬렉션의 모든 문서를 나열할 수 있습니다:

단일 인증되지 않은 curl 요청으로 모든 컬렉션을 열거하는 데 충분합니다. 아래 강조된 블록을 참조하세요.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

응답은 최상위 컬렉션의 전체 목록입니다. 각 컬렉션에 대해 두 번째 요청이 문서를 반환합니다. if true 규칙이 익명 트래픽을 받아들이기 때문에 이 경로에는 속도 제한이 없습니다. 한 시간 이내에 수백만 개의 문서가 열거된 Firebase 데이터베이스를 봤습니다.

쓰기 경로에서: {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를 반환하는지 확인하세요.

외부 확인: 프로덕션 URL에 대해 FixVibe 스캔을 실행하세요. baas.firebase-rules 검사는 Firestore, Realtime Database, Storage 규칙을 탐사하고 Firebase Console이 보여주는 것과는 독립적으로 공격자가 발견할 동일한 발견을 보고합니다.

자주 묻는 질문

다음 단계

프로덕션 URL에 대해 FixVibe 스캔을 실행하세요 — baas.firebase-rules 검사는 if true가 현재 공개 인터넷에서 악용 가능한지 확인합니다. 스캐너 메커니즘과 Realtime Database 및 Storage에 대한 병렬 탐지에 대해서는 Firebase 규칙 스캐너를 참조하세요. Supabase의 동등한 설정 오류 클래스는 Supabase RLS 스캐너를 읽으세요.