← Terug naar de blog
BeveiligingScanaris Team · 2 min lezen · July 11, 2026

De meest voorkomende beveiligingsfouten in Firebase

Firebase is handig omdat het je app zonder backend aan een database koppelt, maar dat gemak is ook de valkuil: de beveiliging hangt bijna volledig af van de regels die je schrijft. Dit zijn de fouten die het meest voorkomen.

De regels in testmodus laten

Als je Firestore of de Realtime Database aanmaakt, biedt Firebase een testmodus die iedereen een tijdje laat lezen en schrijven. Handig om te beginnen, maar veel mensen lanceren met die regels nog aan. Het gevolg: iedereen kan je hele database lezen en aanpassen vanuit de browserconsole.

Verander vóór de lancering de regels zodat ze authenticatie eisen en elke gebruiker tot zijn eigen data beperken.

De publieke sleutel verwarren met beveiliging

De Firebase-config die je in de frontend plakt (apiKey, projectId, enz.) is openbaar bij ontwerp en is geen geheim. Dat verwart veel mensen: ze nemen aan dat Google 'm beschermt omdat die in de client leeft. Dat is niet zo. Wat je data beschermt zijn de beveiligingsregels, niet het verbergen van die sleutel. Het tegendeel aannemen leidt tot open databases.

Regels die alles laten lezen

Een regel als allow read: if true laat je collecties open voor iedereen. De klassieke fout is de regels versoepelen tot de app geen fouten meer geeft en ze nooit meer aanscherpen. Schrijf regels per collectie: check request.auth en vergelijk de gebruiker met de eigenaar van het document.

Gevoelige data in leesbare documenten

Zelfs als je een login vereist, kijk na wat je opslaat. E-mails, adminrollen of interne vlaggen in documenten die elke ingelogde gebruiker kan lezen zijn nog steeds een lek. Scheid privédata in collecties met strengere regels en ga er niet van uit dat niemand kijkt.

Andere sleutels verstopt in de bundle

De Firebase-config is openbaar, maar reist meestal mee met andere sleutels die dat niet zijn: tokens voor betaal-, e-mail- of AI-diensten. Die zijn geheim en mogen niet in browser-JavaScript belanden. AI bakt ze er soms in om iets snel werkend te krijgen.

Scanaris spot wat er is blootgesteld

Scanaris draait read-only checks tegen je gepubliceerde site: het zoekt naar sleutels en secrets die in de frontend zijn blootgesteld, bereikbare gevoelige bestanden en zwakke headerinstellingen. Het exploiteert niets; het kijkt alleen naar wat al openbaar is en waarschuwt je. Elke bevinding komt met een prompt om het in je AI op te lossen. Scan je app voordat iemand anders het doet.

Hoe staat je site ervoor?

Laat Scanaris er even overheen gaan en check het in 30 seconden, gratis.

Mijn site scannen

Gerelateerde checks

Beveiligingsgidsen per stack