Firebase security rules bepalen wie de data in uw Firestore-database, Realtime Database en Cloud Storage mag lezen en schrijven. Draait uw AI-gebouwde app op Firebase, dan hoort een controle van die rules op de lijst vóór de lancering of vóór de eerste betalende klanten.
Deze gids is voor iedereen die een AI-gebouwde app op Firebase draait en nooit security rules hoefde te lezen. U leest wat de rules doen, welke vijf gaten een AI-gebouwd project kan hebben en welke drie controles u zelf uitvoert of door uw developer laat tonen. Ook staat erin wat de AVG (GDPR) aan u overlaat. De gids hoort bij onze serie over AI-gebouwde producten veilig in productie.
TL;DR
Firebase security rules zijn regels op de server die bepalen wat elke leesactie en schrijfactie naar Firestore, Realtime Database en Cloud Storage mag doen. De app praat rechtstreeks met de database, vanaf de telefoon of in de browser, dus de security rules zijn de enige poort. Toegang volgt zodra één passende rule die toestaat, waardoor één te losse rule data kan openen die strengere rules beschermen.
- Vijf gaten: test-mode-rules of allow-all-rules, Admin SDK-code die de rules overslaat, inlogcontroles zonder eigenaarscontrole, te ruime Cloud Storage-rules en ongevalideerde schrijfacties zonder App Check.
- Drie controles die u zelf kunt doen: lees de Rules tab, test wat een uitgelogde bezoeker en een tweede account kunnen lezen en controleer dat elk pad met persoonsgegevens de eigenaar toetst.
- De drempel: elke rode vlag op een collectie of bucket met persoonsgegevens lost u op voordat er meer gebruikers bijkomen.
Wat zijn Firebase security rules?
Firebase security rules zijn toegangsregels die de servers van Google afdwingen bij elke leesactie en schrijfactie naar Cloud Firestore, Realtime Database en Cloud Storage. De app op een telefoon of in een browser kan ze niet omzeilen, omdat de controle op de server plaatsvindt en niet in de code van de app.
In een traditionele opzet praat de app met uw eigen server, en die server bepaalt wat elke gebruiker mag zien. Een Firebase-app praat rechtstreeks met de database. Er staat geen backend voor uw Firebase-database: de security rules zijn de backend voor toegang.
Elke rule noemt een pad, zoals een collectie facturen, en een voorwaarde. De voorwaarde kan kijken wie het verzoek doet via request.auth, de identiteit van de ingelogde gebruiker.
Twee gedragingen bepalen de rest van deze gids. Ten eerste wint één allow: bij meerdere rules op hetzelfde pad geldt in Firestore en Cloud Storage dat toegang wordt verleend zodra één ervan die toestaat. Een strenge rule voor facturen helpt niet als een bredere rule alles toestaat. Ten tweede slaat servercode die de Admin SDK gebruikt, zoals een Cloud Function, security rules volledig over.
Vijf gaten in de Firebase security rules van AI-gebouwde apps
De vijf gaten hieronder laten elk een vreemde of een andere gebruiker bij data waar de schermen van de app nooit naar verwijzen. Elk gat blokkeert de lancering als het getroffen pad persoonsgegevens bevat.
| Gat | Hoe het eruitziet | Wat een vreemde of andere gebruiker kan doen | Blokkeert de lancering? |
|---|---|---|---|
| Test-mode-rules en allow-all-rules | De rules bevatten het woord ‘true’ of een datum | Iedereen op internet kan de data lezen, wijzigen of verwijderen zonder in te loggen | Ja |
| Admin SDK-toegang | Een Cloud Function haalt data op zonder te controleren wie het vraagt | Elke aanroeper van die functie krijgt data die de rules hadden geweigerd | Ja, als er persoonsgegevens zijn opgeslagen |
| Authenticatie zonder autorisatie | De rules controleren alleen ‘ingelogd’ en niets anders | Elk account, ook een nieuw aangemaakt, kan de records van alle gebruikers lezen | Ja, als er persoonsgegevens zijn opgeslagen |
| Te ruime Cloud Storage-rules | Geüploade bestanden hebben geen rule per gebruiker en geen limiet op grootte en type | Een andere gebruiker kan de bestanden van uw klanten openen of bestanden van elk type uploaden | Ja, als er persoonsgegevens zijn opgeslagen |
| Ongevalideerde schrijfacties en ontbrekende App Check | Gebruikers kunnen elk veld van hun eigen record aanpassen, ook rol of abonnement | Een gebruiker kan zichzelf admin maken of upgraden zonder te betalen | Ja, als er persoonsgegevens zijn opgeslagen |
Test-mode-rules en allow-all-rules in productie
Een allow-all-rule laat iedereen op internet met de publieke configuratie van uw app de data die de rule dekt lezen, wijzigen of verwijderen, zonder in te loggen. Test-mode-rules doen hetzelfde tot een vaste datum. Die configuratie zit in elke kopie van de app, dus het is geen wachtwoord.
Een Firebase-database kan in test mode starten, met rules die elke leesactie en schrijfactie toestaan tot een vervaldatum. Verloopt die datum, dan stopt de app met werken; verlengt iemand de datum, dan blijft de data open. Een tweede route is de foutmelding ‘permission denied’: komt een AI-codingtool die tegen, dan is de kortste aanpassing die de fout laat verdwijnen een bredere rule.
Zoek in de rules naar een voorwaarde die simpelweg true is (allow read, write: if true;), waarvan de documentatie van Firebase zelf zegt dat u die nooit in productie gebruikt. Zoek ook naar een datum, naar .read of .write op true op het hoogste niveau van een Realtime Database en naar een match op de hele database, die elke strengere rule overstemt omdat één allow wint. Is uw rules-bestand sinds de eerste projectweek niet gewijzigd, ga er dan van uit dat het nog de test mode weerspiegelt.
Admin SDK-toegang: rules omzeild, credentials blootgesteld
Code die de Firebase Admin SDK gebruikt, inclusief Cloud Functions en uw eigen servers, omzeilt security rules volledig. Een Cloud Function die een record teruggeeft zonder te controleren wie het vraagt, geeft dat record aan elke aanroeper, hoe streng de rules ook zijn. Elke functie heeft daarom een eigen eigenaarscontrole nodig.
Dit gat kan ontstaan uit een begrijpelijke oplossing. Blokkeren security rules een functie, dan kan de logica verhuizen naar een Cloud Function die met adminrechten leest. De rules lijken in de console nog strak, terwijl de functie een zijdeur is geworden.
De Admin SDK logt in met een service account key, die Firebase developers vraagt veilig op te slaan. Een service account key die in de app zit of in een openbare repository staat, geeft de houder dezelfde adminrechten. Lees ook onze gids over secrets in frontendcode.
Authenticatie zonder autorisatie (ontbrekende eigenaarscontroles)
Een rule die alleen controleert of iemand is ingelogd, laat elk account de records van alle gebruikers lezen, ook een account dat een vreemde een minuut geleden heeft aangemaakt. Authenticatie stelt vast wie een gebruiker is; autorisatie bepaalt waar die gebruiker bij mag. Rules die bij authenticatie stoppen, houden bezoekers buiten, geen andere gebruikers.
Het patroon is request.auth != null zonder iets erachter. De documentatie van Firebase toont die rule als beginpunt en stelt dat ze niet aanbevolen is voor productie-apps. De rule kan tot de lancering blijven staan omdat de bouwer inlogt met één account dat alle testdata bezit, waardoor een ontbrekende eigenaarscontrole nooit op het scherm verschijnt.
Een veilige rule vergelijkt het ID van de ingelogde gebruiker (request.auth.uid) met de eigenaar die op het document staat. Een ontbrekende eigenaarscontrole is de meest directe vorm van broken access control.
Te ruime Cloud Storage-rules en uploadrules
Bestanden die gebruikers uploaden, zoals identiteitsbewijzen, facturen en foto’s, worden beschermd door Cloud Storage-rules, die los van de databaserules staan. Laten de Storage-rules elke ingelogde gebruiker alle bestanden lezen, dan beschermen strakke Firestore-rules die bestanden niet en kan de ene klant de documenten van de andere openen.
Storage-rules blijven makkelijk achter, omdat het werk aan rules de foutmeldingen volgt en de eerste foutmeldingen in de database verschijnen. Cloud Storage-rules kunnen de grootte en het type van een upload beperken; zonder die limieten kan een gebruiker bestanden van elke grootte of soort in uw bucket zetten. De signalen zijn een Storage-rule die alleen inloggen controleert en een bestandspad zonder map per gebruiker.
Ongevalideerde schrijfacties en ontbrekende App Check
Een rule waarmee gebruikers hun eigen profielrecord bijwerken zonder te beperken welke velden ze mogen wijzigen, laat hen elk veld erin wijzigen. Bevat dat record ook een rol, een abonnement of een tegoed, dan kan een gebruiker zichzelf admin maken of zonder te betalen naar een betaald abonnement overstappen.
Security rules kunnen de binnenkomende data controleren en wijzigingen weigeren in velden die een gebruiker niet hoort te bepalen. Voor rollen houdt het veiligere ontwerp ze helemaal buiten records die gebruikers zelf kunnen schrijven. Custom claims zijn labels op het inlogtoken van een gebruiker, alleen in te stellen vanuit servercode via de Admin SDK en leesbaar in security rules.
App Check is een Firebase-dienst die verifieert dat verzoeken van uw echte app komen en niet van een script. App Check vervangt security rules niet: een echte app in handen van een nieuwsgierige gebruiker stuurt nog steeds verzoeken, en de security rules bepalen wat die verzoeken mogen lezen of schrijven.
Zo controleert u uw Firebase security rules
Drie controles laten zien of uw Firebase-rules openstaan. De eerste voert u zelf uit; de andere twee laat u door uw developer tonen.
Bekijk uw Rules tab
De Rules tab in de Firebase-console toont de security rules die nu live staan, en ze scannen op rode vlaggen vraagt geen programmeerkennis. Open de tab voor elk product dat de app gebruikt: Firestore, Realtime Database en Storage. Zoek naar de vier rode vlaggen uit Tabel 1: het woord ‘true’ als voorwaarde, een datum, een inlogcontrole zonder iets erachter en een match op de hele database.
Firebase kan een project ook waarschuwen dat de data niet goed beveiligd is. Behandel zo’n waarschuwing als een bevinding en stuur haar door naar uw developer.
Zie wat een uitgelogde bezoeker en een tweede account kunnen zien
De tweede controle test de security rules in plaats van ze te lezen. Kan een uitgelogde bezoeker iets lezen, en kan account B de data van account A lezen? Voor elk pad met persoonsgegevens moet het antwoord twee keer nee zijn.
De Rules Playground in de Firebase-console simuleert één leesactie of schrijfactie als uitgelogde of ingelogde gebruiker, voor Firestore, Realtime Database en Storage. Voor herhaalbaar bewijs vraagt u uw developer om vóór elke deploy tests als uitgelogde gebruiker en als tweede account te draaien in de Firebase Local Emulator Suite en u het testbestand te tonen.
Een testbestand zonder test met een tweede account is zelf een bevinding. De volledige methode staat in onze gids over AI-applicaties testen.
Controleer of elk pad met persoonsgegevens de eigenaar toetst
De derde controle is een gesprek met uw developer over dekking: elke plek met persoonsgegevens hoort een rule te hebben die de eigenaar noemt. Stel drie vragen en vraag de antwoorden schriftelijk.
- “Welke collecties en Storage-paden bevatten persoonsgegevens, en welke rule beschermt elk ervan?”
- “Welke velden kan een gebruiker op zijn eigen record schrijven?”
- “Welke Cloud Functions gebruiken de Admin SDK, en wat controleert elke functie voordat ze data leest of schrijft?”
In de Rules tab is niets te zien van een functie die de rules overslaat, dus de derde vraag verdient de meeste aandacht. Hanteer één drempel voor alle drie de controles: elke rode vlag op een collectie of bucket met persoonsgegevens lost u op voordat er meer gebruikers bijkomen.
Vond u een datum, een ‘true’ of een rule die alleen controleert of iemand is ingelogd? Dan kan uw data verder openstaan dan de schermen van de app doen vermoeden. In een onafhankelijke review leest Sunbytes uw security rules samen met de Cloud Functions die ze omzeilen en vertelt in begrijpelijke taal wat u eerst dichtzet.
Is Firebase veilig genoeg voor een productie-app?
Firebase is veilig genoeg voor een productie-app als de security rules op eigenaarschap zijn gebaseerd, getest en beoordeeld, en een risico als de rules na de test mode nooit zijn aangepast. Het platform is niet de variabele. Google beveiligt de infrastructuur; u bezit de rules, het datamodel en alle code die de Admin SDK gebruikt. Die verdeling heet gedeelde verantwoordelijkheid.
Voor een Europees bedrijf liggen twee beslissingen aan uw kant van die verdeling.
Datalocatie. Een Firestore-database wordt aangemaakt op een locatie die u kiest, en die locatie kan achteraf niet worden gewijzigd. Firebase biedt een Europese multi-regio en afzonderlijke Europese regio’s, zoals Frankfurt. Een Amerikaanse database naar Europa verhuizen betekent een nieuwe database aanmaken en de data migreren.
AVG-rollen en beveiliging. Onder de Firebase Data Processing and Security Terms van Google is Google verwerker van persoonsgegevens van klanten wanneer Europese privacywetgeving van toepassing is. Bepaalt uw bedrijf waarom en hoe die data wordt gebruikt, dan is uw bedrijf de verwerkingsverantwoordelijke. AVG-artikel 28 vereist een overeenkomst tussen verwerkingsverantwoordelijke en verwerker, en artikel 32 vereist beveiligingsmaatregelen die passen bij het risico. Security rules die persoonsgegevens voor elk account leesbaar laten, zijn lastig te verdedigen onder artikel 32. Deze alinea is algemene informatie, geen juridisch advies.
Bevestig de datalocatie en de staat van uw security rules voordat een B2B-klant er in een securityvragenlijst naar vraagt.
Firebase security rules en Supabase RLS: hetzelfde probleem, andere laag
Firebase security rules en Supabase Row Level Security (RLS) lossen hetzelfde probleem op in verschillende lagen: beide bepalen welke gebruiker bij welke data mag als de app rechtstreeks met de database praat. Geen van beide platforms is standaard veiliger. De veiligere keuze is het platform waarvoor uw team toegangsrules kan schrijven en testen.
| Criterium | Firebase security rules | Supabase RLS |
|---|---|---|
| Waar de rules staan | In een rules-bestand per product (Firestore, Realtime Database, Storage), afgedwongen door Firebase | In policies op elke databasetabel, afgedwongen door de Postgres-database |
| Taal | De eigen rules-taal van Firebase (JSON voor Realtime Database) | SQL |
| Gat om op te letten in een AI-gebouwd project | Test-mode-rules of een inlogcontrole zonder eigenaarscontrole | RLS uitgeschakeld op een tabel, of een policy die elke rij toestaat |
| Pad dat de rules overslaat | Servercode met de Admin SDK | Servercode met de service_role-key |
| Hoe u test | Rules Playground en tests in de Local Emulator Suite | Verzoeken als uitgelogde gebruiker en als tweede gebruiker |
Stapt u van het ene platform over naar het andere, beoordeel dan de rules aan beide kanten voordat u het verkeer omzet. Eigenaarscontroles uit Firebase security rules werken niet door in Supabase-policies, en omgekeerd. De Supabase-kant staat in onze gids over Supabase RLS.
Zo dicht u de gaten zonder de app te breken
Firebase-rules veilig dichten betekent aanscherpen in een vaste volgorde en elke stap testen, omdat een te strenge rule functies voor echte gebruikers breekt. Zeven stappen dekken de vijf gaten:
- Begin bij deny-all.
- Voeg eigenaarsrules per collectie toe. Elke rule vergelijkt de ingelogde gebruiker met de eigenaar op het record.
- Valideer schrijfbare velden en weiger wijzigingen in de rest.
- Verplaats rollen naar custom claims die servercode instelt.
- Vergrendel Storage-paden per gebruiker en beperk bestandsgrootte en bestandstype.
- Test in de Emulator als uitgelogde bezoeker, als eigenaar en als tweede account.
- Deploy rules los van de app-code. Security rules staan buiten de app, dus een wijziging kan zonder nieuwe appversie worden uitgebracht en teruggedraaid.
App Check is een extra laag bovenop deze stappen en vervangt er geen. De Firebase web API key identificeert het project en is geen secret. Service account keys en API keys van derden zijn wel secrets en horen nooit in de app te zitten.
Klaar betekent dat drie dingen waar zijn: geen enkele rule bevat ‘true’ of een datum, elk pad met persoonsgegevens toetst de eigenaar en de Emulator-tests draaien bij elke deploy.
Zo reviewt Sunbytes producten die op Firebase draaien
Strakke rules dekken maar de helft van een Firebase-app: elke Cloud Function met de Admin SDK slaat ze over, dus de code achter de rules verdient dezelfde aandacht. Een AI-built product review van Sunbytes leest daarom de security rules, het datamodel en de servercode in één keer, waarbij software engineering en security samen worden bekeken.
U krijgt de bevindingen, het bewijs achter elke bevinding en een plan voor wat u eerst oplost, in begrijpelijke taal. Een technische overdracht vertelt uw developer of AI-codingtool wat te doen. Het werk staat onder Nederlandse leiding, met engineering in Vietnam, binnen een ISO 27001-gecertificeerd ISMS, en rust op 15+ jaar ervaring en 300+ opgeleverde projecten.
Het bereik hangt af van uw product, dus neem contact met ons op voor advies per situatie. Staat een lancering in de store voor de deur, dan noemt onze gids over de review van een AI-gebouwde mobiele app de controles vóór indiening.
