Firebase 규칙 스캐너: 열린 Firestore, Realtime Database, Storage 규칙 찾기

스캐너가 열린 Firebase 규칙을 찾는 방법

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

• Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
• Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
• Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

테스트 모드 함정이 실제로 어떤 모습인지

Firebase의 빠른 시작 문서에는 인터넷에서 가장 많이 복사된 규칙 블록 중 하나가 포함되어 있습니다:

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

Firebase는 이전에 이러한 규칙에 자동 30일 만료를 추가했습니다. 변경되었습니다: 오늘날 개발자가 교체하지 않는 한 규칙은 영원히 지속됩니다. AI 코딩 도구는 — 테스트 모드 블록을 포함하는 수년간의 문서로 훈련되어 — 이를 그대로 자주 내보내며 개발자에게 "이것이 보안 규칙입니다"라고 말합니다. 그렇지 않습니다.

프로덕션에 나타나지만 똑같이 허용적인 다른 변형:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• 미래 타임스탬프 변형: 먼 미래 날짜까지 모든 것을 허용하는 규칙. 사실상 결코 만료되지 않습니다(위의 강조된 블록 참조).
• allow read: if true; allow write: if request.auth != null; — 공개 읽기, 모든 인증된 사용자가 쓸 수 있음.
• allow read, write: if request.auth != null; — 로그인한 모든 사용자가 다른 사용자의 데이터를 포함한 모든 문서를 읽거나 쓸 수 있음.

스캐너가 열린 규칙을 발견했을 때 할 일

열린 Firebase 규칙은 런타임 비상 사태입니다. 수정은 세 서비스 모두 동일한 모양입니다: 모든 규칙을 명시적 소유자 필드에 대해 request.auth.uid로 범위를 좁히세요. 각 서비스는 자체 규칙 구문이 있습니다:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. 경로 세그먼트 바인딩 {userId}가 사용자가 접근할 수 있는 유일한 문서가 됩니다.

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

실시간 데이터베이스

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }. $uid 와일드카드는 비교를 위해 경로 세그먼트를 캡처합니다.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

클라우드 스토리지

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. 관례: 파일을 users/[uid]/[filename] 하위에 저장하고 경로가 소유권을 강제하도록 하세요.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Firebase 내장 도구와의 비교

Firebase Console은 현재 규칙을 보여주지만 런타임 동작에 대해 감사하지 않습니다. Firebase Rules 시뮬레이터는 합성 요청에 대해 규칙 로직을 테스트할 수 있게 합니다 — 유용하지만 로컬입니다. 두 도구 모두 프로덕션 규칙이 공개 인터넷의 익명 공격자에게 실제로 무엇을 반환하는지 알려주지 않습니다. FixVibe(또는 수동 구성이 있는 Burp Suite) 같은 외부 스캐너만이 공격자와 동일한 각도에서 탐사합니다. Google 자체 App Check는 남용을 완화하지만 올바르게 범위가 좁혀진 규칙을 대체하지 않습니다.

자주 묻는 질문

다음 단계

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.