// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true uitgelegd: wat het doet en hoe je het oplost

Q: Wat is het verschil tussen if true en if request.auth != null ?

if true staat anonieme toegang toe — iedereen op het internet. if request.auth != null vereist een ingelogde gebruiker, wat beter is maar nog steeds verkeerd: elke gebruiker van je app kan elk andere gebruikers data lezen. Productieregels moeten scoopen op de specifieke gebruiker of organisatie via request.auth.uid == resource.data.owner_uid of vergelijkbaar.

Q: Verloopt Firebase ooit automatisch if true -regels?

Oudere projecten (pre-2023) hadden een 30-dagen-timer die if true-regels omzette naar if false. Huidige projecten niet — de regel persisteert onbepaald totdat handmatig vervangen. Als je je project vóór 2023 hebt aangemaakt en je regels er goed uitzien, controleer dubbel: de timer heeft ze mogelijk al omgedraaid naar if false, wat je eigen app blokkeert.

Q: Wat als mijn app echt openbaar-leesbaar is (blog, productcatalogus)?

Schrijf dan expliciet allow read: if true; allow write: if false; op alleen de openbare collectie — niet op elke collectie in je database. Gebruik een aparte match-clausule per collectie en gebruik nooit de recursieve '{'document=**'}'-wildcard op schrijfbare regels.

<code>allow read, write: if true;</code> is de meest voorkomende Firebase-misconfiguratie in productie. Het is de testmodus-standaard die de Firebase Console voorstelt wanneer je een nieuwe database aanmaakt, de regel die AI-codeertools regenereren uit documentatie, en de regel die je hele Firestore-database opent voor iedereen op het internet. Dit artikel legt de syntaxis precies uit, laat zien wat een aanvaller ziet wanneer deze regel actief is, en geeft je vier progressief strengere vervangingen die passen bij verschillende use cases.

De syntaxis, regel voor regel

Een volledig Firestore-testmodus-regeldocument bestaat uit zes regels:

firebase

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

Gedecodeerd:

rules_version = '2'; selecteert de v2-regelsengine (huidig). Oudere v1-regels zijn afgekeurd.
service cloud.firestore scoopt het blok naar Firestore. Realtime Database gebruikt een andere JSON-gebaseerde syntaxis; Cloud Storage gebruikt service firebase.storage.
match /databases/{database}/documents bindt de speciale (default)-database (de meeste projecten hebben er maar één).
match /{document=**} is een recursieve wildcard. De ** matcht elk pad van elke diepte. Gecombineerd met {document}, vangt dit elk document in elke collectie — een enkele match-clausule die de hele database beheert.
allow read, write: if true; is het regelbody. Zowel read als write zijn toegestaan; de voorwaarde if true is, nou ja, altijd waar. read dekt get- en list-operaties; write dekt create, update en delete.

Netto-effect: elke client met de Firebase-project-ID en de juiste SDK kan elk document in elke collectie lezen of schrijven. Authenticatie is niet vereist. Rate limits worden niet afgedwongen.

Waarom Firebase dit als de standaard levert

Firebase wil dat je codeert in de eerste 30 seconden na het aanmaken van een project. Het alternatief — je laten een correcte regel schrijven voordat enige lees- of schrijfactie werkt — zou onboarding blokkeren. Dus de Console biedt twee opties wanneer je een database aanmaakt: Productiemodus (alles weigeren, jij schrijft de regels) of Testmodus (alles toestaan voor 30 dagen). De meeste ontwikkelaars klikken op testmodus en vergeten het dan opnieuw te bezoeken. Oudere projecten hadden de 30-dagen-timer; huidige projecten hebben een onbepaalde if true-regel zonder automatische vervaltijd.

Het structurele probleem: AI-codeertools trainen op documentatie, tutorials en Stack Overflow-antwoorden die testmodusregels tonen. Wanneer je Cursor of Claude Code vraagt "hoe stel ik Firebase in", bevat het antwoord vaak het exacte allow read, write: if true-blok alsof het de productieregel is. De AI weet niet — en wordt niet gevraagd te weten — dat deze regel niet veilig is voor productie.

Wat een aanvaller ziet

Concreet kan een aanvaller die je Firebase-project-ID kent (extraheerbaar uit de bundle van elke gedeployde app in 30 seconden) en het volgende uitvoert, elk document in elke collectie oplijsten:

Een enkele niet-geauthenticeerde curl-aanvraag is genoeg om elke collectie op te sommen. Zie het gemarkeerde blok hieronder.

bash

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

Het antwoord is de volledige lijst van top-level collecties. Voor elke collectie retourneert een tweede aanvraag documenten. Er is geen rate limit op dit pad omdat if true-regels anoniem verkeer accepteren. We hebben Firebase-databases gezien met miljoenen documenten die in minder dan een uur werden opgesomd.

Op het schrijfpad: een enkele POST met {fields} maakt een nieuw document aan. Aanvallers kunnen je collecties vervuilen met rommel, op gebruikers gerichte pagina's die uit Firestore lezen ontsieren, of je database gebruiken als een gratis berichtenmakelaar — je gebruikersrekening piekt, je onderzoekt, en de rekening verklaart het probleem.

Vier productieveilige vervangingen

Kies de vervanging die past bij het datamodel van je app. Alle vier veronderstellen dat je gebruikersauthenticatie hebt (Firebase Auth of een andere provider die een Firebase-ID-token uitgeeft):

Optie 1: Door gebruikers bezeten documenten

Meest voorkomende SaaS-patroon. Documenten leven onder /users/{userId}/... en alleen de eigenaar kan ze aanraken. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

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

Optie 2: Eigenaarsveld op elk document

Wanneer documenten in platte collecties leven (niet genest onder gebruikers-ID), sla een owner_uid-veld op en controleer het. 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; }

firebase

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

Optie 3: Multi-tenant organisatie-isolatie

Voor B2B-SaaS met org-gescoopte data. Sla een org_id-veld op op elk document en controleer het tegen de aangepaste claim van de gebruiker. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Vereist het instellen van de aangepaste claim tijdens registratie via Firebase Admin SDK.

firebase

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

Optie 4: Alleen-lezen openbare inhoud

Voor marketinginhoud, openbare profielen, productcatalogi — alles wat echt openbaar-leesbaar is maar alleen-admin-schrijfbaar. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. De admin aangepaste claim wordt alleen ingesteld op admin-accounts.

firebase

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

Snelle audit-query

Voordat je oplost, controleer of if true daadwerkelijk live is. Open Firebase Console → Firestore → Rules en zoek naar if true. Als je het ergens buiten een commentaar vindt, heb je een open-regel-bevinding. De Rules-simulator in dezelfde UI laat je het verzoek van de aanvaller lokaal herhalen — plak een anonieme GET /users/somebody en bevestig dat de simulator Allowed retourneert.

Externe bevestiging: voer een FixVibe-scan uit tegen je productie-URL. De baas.firebase-rules-check sondeert je Firestore-, Realtime Database- en Storage-regels en rapporteert dezelfde bevinding die een aanvaller zou ontdekken — onafhankelijk van wat de Firebase Console toont.

Veelgestelde vragen

Wat is het verschil tussen <code>if true</code> en <code>if request.auth != null</code>?

if true staat anonieme toegang toe — iedereen op het internet. if request.auth != null vereist een ingelogde gebruiker, wat beter is maar nog steeds verkeerd: elke gebruiker van je app kan elk andere gebruikers data lezen. Productieregels moeten scoopen op de specifieke gebruiker of organisatie via request.auth.uid == resource.data.owner_uid of vergelijkbaar.

Verloopt Firebase ooit automatisch <code>if true</code>-regels?

Oudere projecten (pre-2023) hadden een 30-dagen-timer die if true-regels omzette naar if false. Huidige projecten niet — de regel persisteert onbepaald totdat handmatig vervangen. Als je je project vóór 2023 hebt aangemaakt en je regels er goed uitzien, controleer dubbel: de timer heeft ze mogelijk al omgedraaid naar if false, wat je eigen app blokkeert.

Kan ik een toekomstige-datum-tijdstempelcontrole gebruiken als vangnet?

Nee — een tijdstempelvoorwaarde is geen beveiligingscontrole. Het verloopt de open regel op een toekomstige datum, wat betekent dat aanvallers tot die datum volledige toegang hebben. En je vergeet de datum. Vervang if true door een auth-gescoopte regel, niet een tijd-gebonden.

Wat als mijn app echt openbaar-leesbaar is (blog, productcatalogus)?

Schrijf dan expliciet allow read: if true; allow write: if false; op alleen de openbare collectie — niet op elke collectie in je database. Gebruik een aparte match-clausule per collectie en gebruik nooit de recursieve {document=**}-wildcard op schrijfbare regels.

Volgende stappen

Voer een FixVibe-scan uit tegen je productie-URL — de baas.firebase-rules-check bevestigt of if true momenteel uitbuitbaar is vanaf het openbare internet. Voor de scanner-mechanica en de parallelle detecties voor Realtime Database en Storage, zie Firebase-regelsscanner. Voor de equivalente klasse van misconfiguratie op Supabase, lees Supabase RLS-scanner.