Firebase-regelsscanner: vind open Firestore-, Realtime Database- en Storage-regels

Hoe de scanner open Firebase-regels vindt

Firebase-diensten stellen bekende, voorspelbare URL-vormen bloot. Een scanner zonder credentials kan elk onderzoeken en observeren of anonieme reads slagen. De baas.firebase-rules-check van FixVibe draait in drie onafhankelijke sondes — één per Firebase-dienst:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. De scanner sondeert https://[project-id]-default-rtdb.firebaseio.com/.json. Als de root anoniem leesbaar is, is het antwoord de hele databaseboom als JSON. Een conservatievere test bevraagt .json?shallow=true, die alleen sleutels op het hoogste niveau retourneert — een bevinding hoe dan ook.
• Cloud Storage. De scanner bevraagt https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Als het antwoord bestandsnamen oplijst zonder authenticatie, is de bucket anoniem oplijstbaar. Oplijstbare opslag is een bevinding zelfs wanneer individuele bestandsdownloads worden geweigerd — aanvallers somen de bucket op om raadbare bestandsnamen te vinden.

Hoe de testmodus-voetangel er echt uitziet

De quickstart-documentatie van Firebase bevat een van de meest-gekopieerde regelblokken op het internet:

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

Firebase voegde vroeger een automatische 30-dagen-vervaltijd toe aan deze regels. Dat is veranderd: vandaag persisteren de regels voor altijd, tenzij de ontwikkelaar ze vervangt. AI-codeertools — getraind op jaren documentatie die het testmodus-blok bevat — produceren het vaak woordelijk en vertellen de ontwikkelaar "dit is je beveiligingsregel". Dat is het niet.

Andere varianten die in productie verschijnen maar even tolerant zijn:

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

• Een toekomstige-tijdstempel-variant: een regel die alles toestaat tot een datum ver in de toekomst. Verloopt nooit effectief (zie het gemarkeerde blok hierboven).
• allow read: if true; allow write: if request.auth != null; — openbare reads, elke geauthenticeerde gebruiker kan schrijven.
• allow read, write: if request.auth != null; — elke ingelogde gebruiker kan elk document lezen of schrijven, inclusief de gegevens van andere gebruikers.

Wat te doen wanneer de scanner een open regel vindt

Open Firebase-regels zijn een runtime-noodsituatie. De fix heeft dezelfde vorm over alle drie de diensten: scoop elke regel naar request.auth.uid tegen een expliciet eigenaarsveld. Elke dienst heeft zijn eigen regelsyntaxis:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. De padsegmentbinding {userId} wordt het enige document dat de gebruiker kan aanraken.

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

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

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Conventie: sla bestanden op onder users/[uid]/[filename] en laat het pad eigenaarschap afdwingen.

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

Deploy regels via de Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifieer dat de nieuwe regels in productie zijn door de FixVibe-scan opnieuw uit te voeren — de baas.firebase-rules-bevinding zou moeten verdwijnen.

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

Hoe dit zich verhoudt tot de ingebouwde tools van Firebase

De Firebase Console laat je de huidige regels zien maar audit ze niet tegen runtime-gedrag. De Firebase Rules-simulator laat je regellogica testen tegen synthetische aanvragen — nuttig maar lokaal. Geen van beide tools vertelt je wat je productieregels daadwerkelijk retourneren aan een anonieme aanvaller op het openbare internet. Een externe scanner zoals FixVibe (of Burp Suite met handmatige configuratie) is het enige dat sondeert vanuit dezelfde hoek als een aanvaller. Google's eigen App Check mitigeert misbruik maar vervangt niet correct gescoopte regels.

Veelgestelde vragen

Volgende stappen

Voer een gratis FixVibe-scan uit tegen je productie-URL — de baas.firebase-rules-check wordt geleverd op elk plan en markeert open regels in Firestore, Realtime Database en Cloud Storage. Voor een diepere uitleg specifiek over het allow read, write: if true-patroon, zie Firebase allow read, write: if true uitgelegd. Voor het paraplu-overzicht over Supabase, Firebase, Clerk en Auth0, lees BaaS-misconfiguratiescanner.