Voorbeelden van Firebase security rules

Q: Hoeveel get()-aanroepen mag één rule doen?

Firebase documenteert een limiet van 10 documenttoegangsaanroepen voor verzoeken en queries op één document, en 20 voor lezingen van meerdere documenten, transacties en batch-schrijfacties. Gaat u daaroverheen, dan volgt een permission denied-fout.

Q: Gelden security rules voor mijn servercode?

Nee. Rules beschermen verzoeken van mobiele en webclients. Firebase stelt dat de serverclientbibliotheken alle Cloud Firestore Security Rules omzeilen, dus controleer invoer in uw servercode apart.

Q: Hoe test ik rules zonder live gegevens aan te raken?

Start de emulator met firebase emulators:start --only firestore en schrijf dan tests met het pakket @firebase/rules-unit-testing, met assertSucceeds en assertFails voor toegestane en geblokkeerde acties.

Voorbeelden van Firebase security rules: Firestore, Storage, RTDB | We.Inc

Firebase security rules om te kopiëren voor gegevens van alleen de eigenaar, publiek lezen, adminrollen en validatie in Firestore, Storage en Realtime Database, plus hoe u ze test.

Voorbeelden van Firebase security rules

Firebase security rules bepalen wie elk stukje gegevens in uw app mag lezen en schrijven. Begin elk Firestore-bestand met rules_version = '2', geef alleen toegang als request.auth is ingesteld, vergelijk request.auth.uid met de eigenaar van het document en controleer binnenkomende velden met request.resource.data. Test met de emulator voordat u deployt.

De variabelen die u per product het meest gebruikt

Product
Ingelogde gebruiker
Gegevens die worden geschreven

Cloud Firestore

Cloud Storage
request.resource (size, contentType)

Realtime Database
newData

Als uw app, webwinkel of ledenomgeving gegevens in Firebase opslaat, zijn de rules het enige wat tussen de gegevens van uw klanten staat en iedereen die de openbare config van uw project heeft. De recepten hieronder dekken de gevallen die de meeste kleine apps nodig hebben. Filter op product, kopieer er een en pas de collectienamen aan uw eigen namen aan.

Kies het recept dat bij uw situatie past en kopieer het naar uw rules-bestand.
Hernoem de collectie- of padnamen, zoals users of orders, zodat ze bij uw database passen.
Draai de rules in de Local Emulator Suite en probeer zowel toegestane als geblokkeerde verzoeken.
Deploy met de Firebase CLI of publiceer in de console zodra de tests slagen.

Rules zijn geen filters. Een query die vraagt om documenten die de gebruiker niet mag lezen, wordt in zijn geheel geweigerd, dus schrijf queries die bij uw rules passen.
Elke aanroep van get() of exists() in een rule wordt gefactureerd als een documentlezing, ook als het verzoek wordt geweigerd, dus houd het aantal lookups laag.
Vergrendel velden die gebruikers nooit mogen wijzigen, zoals een eigenaar-id of een rol, door request.resource.data te vergelijken met resource.data.
Zoek vóór de lancering in uw rules naar if true. Firebase waarschuwt om nooit rules die alles toestaan in productie te gebruiken.

Veelgestelde vragen

Wat is de test mode van Firestore?

Een van de twee startkeuzes bij het aanmaken van een database. Firebase noemt test mode goed om te beginnen, maar zegt dat iedereen dan uw gegevens kan lezen en overschrijven. Production mode weigert alle lees- en schrijfacties van mobiele en webclients totdat u rules schrijft.

Waarom krijgt mijn app ineens permission denied-fouten?

Zoek naar een voorwaarde die request.time vergelijkt met een vaste datum, zoals request.time < timestamp.date(2026, 11, 1). Zodra die datum voorbij is, mislukt elk verzoek. Vervang het door echte rules in plaats van de datum op te schuiven.

Hoeveel get()-aanroepen mag één rule doen?

Firebase documenteert een limiet van 10 documenttoegangsaanroepen voor verzoeken en queries op één document, en 20 voor lezingen van meerdere documenten, transacties en batch-schrijfacties. Gaat u daaroverheen, dan volgt een permission denied-fout.

Gelden security rules voor mijn servercode?

Nee. Rules beschermen verzoeken van mobiele en webclients. Firebase stelt dat de serverclientbibliotheken alle Cloud Firestore Security Rules omzeilen, dus controleer invoer in uw servercode apart.

Hoe test ik rules zonder live gegevens aan te raken?

Start de emulator met firebase emulators:start --only firestore en schrijf dan tests met het pakket @firebase/rules-unit-testing, met assertSucceeds en assertFails voor toegestane en geblokkeerde acties.

Hoe een rule wordt gelezen

Een match-blok noemt een pad, en de allow-regels daarbinnen noemen de acties, zoals read, create, update en delete, met een voorwaarde na if. Toegang wordt verleend als een passende allow-regel waar is; er bestaat geen deny-statement.
resource.data is het document zoals het nu bestaat, en request.resource.data is hoe het er na het schrijven uit zou zien. Door die twee te vergelijken voorkomt u dat iemand een veld wijzigt waar hij niet aan mag komen.

Rollen zonder backend

Een veelgebruikt patroon slaat een role-veld op in elk gebruikersdocument en leest dat met get() in andere rules. Zorg dat gebruikers hun eigen rol niet kunnen bewerken, anders kan iedereen zichzelf tot admin promoveren.
Een alternatief zijn custom claims op het login-token, ingesteld vanuit servercode en gelezen als request.auth.token, wat geen extra documentlezingen kost.

Rules om vóór de lancering te verwijderen

Deze patronen komen voor in starterprojecten en tutorials. Elk ervan laat gegevens open.

Riskante rules en veiligere vervangingen

Riskante rule
Waarom het een probleem is
Vervangen door

allow read, write: if true;
Iedereen kan alles lezen of overschrijven
Controles op eigenaar of rol

allow read, write: if request.time < timestamp.date(...);
Wagenwijd open tot de datum, daarna werkt niets meer
Echte rules per collectie

allow read, write: if request.auth != null;
Elke ingelogde vreemde kan de gegevens van elke gebruiker bewerken
Vergelijk request.auth.uid met de eigenaar

Rules testen met de emulator

Draai de Firestore-emulator en controleer dan dat de eigenaar kan schrijven en een vreemde niet.

Unit test voor rules met @firebase/rules-unit-testing

Gebruikt een demo-project-id zodat er niets een live database bereikt. Voer het uit terwijl firebase emulators:start --only firestore draait.

Profielen alleen voor de eigenaar

Elke gebruiker leest en bewerkt alleen het document waarvan de id gelijk is aan zijn gebruikers-id.

Publiek lezen, admin schrijven

Iedereen kan de productcatalogus lezen; alleen gebruikers met role admin in hun profiel kunnen hem wijzigen.

Nieuwe bestellingen valideren

Een klant kan alleen een bestelling voor zichzelf aanmaken, met een positief totaal en een bekende status, en kan die daarna niet bewerken.

Gebruikers kunnen hun eigen rol niet wijzigen

Profielwijzigingen zijn alleen toegestaan als het role-veld precies blijft zoals het was.

Gebruikers uploaden eigen afbeeldingen onder 5MB

Bestanden staan in de map van elke gebruiker; uploads moeten afbeeldingen kleiner dan 5MB zijn, en iedereen die is ingelogd kan ze bekijken.

Gegevens alleen voor de eigenaar met validatie

Realtime Database-rules zijn JSON. $uid vangt de sleutel op; newData is de waarde die wordt geschreven.

Recepten voor rules

Toon recepten voor

Alle producten

Cloud Firestore

Cloud Storage

Realtime Database

{n} recepten getoond

Gratis beginnen · Geen creditcard nodig

Gerelateerd: Gidsen

Product

Voor wie

Functies

Bronnen

Bedrijf

Sitemap