Firebase ist das Lieblings-Backend vieler mit KI gebauter Apps: Lovable, Bolt oder Cursor binden es in Minuten an, und du hast Authentifizierung, Datenbank und Dateien, ohne einen Server aufzusetzen. Das Problem: Sein Sicherheitsmodell ist das Gegenteil von dem eines klassischen Backends. Hier spricht der Browser direkt mit der Datenbank, es gibt also keinen Server, der Anfragen filtert: Die Sicherheitsregeln sind deine einzige Barriere, und eine schlecht geschriebene Regel legt alle Daten offen. Dieser Guide geht die zehn häufigsten Fehler durch, jeweils mit der falschen und der richtigen Regel, und endet damit, wie du es selbst prüfst.
1. Regeln im Testmodus, oder was danach kommt
Beim Anlegen einer Datenbank bietet dir Firebase den „Testmodus" an: dreißig Tage lang alles offen. Die Regel sieht so aus:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2026, 11, 3);
}
}
}Bis zu diesem Datum kann jeder mit deiner projectId (die im Browser-Code steht) die gesamte Datenbank lesen und schreiben. Und das Schlimmste kommt danach: Beim Ablauf funktioniert die App nicht mehr, der Entwickler sucht eine schnelle Lösung und ersetzt das Datum durch if true. Jetzt ist das Loch dauerhaft. Die Lösung ist, vom ersten Tag an Regeln pro Collection zu schreiben, basierend darauf, wer der Nutzer ist und wem das Dokument gehört.
2. allow read: if true bei Nutzerdaten
Es gibt Collections, die öffentlich sein dürfen (ein Produktkatalog, Blogbeiträge). Aber allow read: if true bei users, orders oder messages heißt, dass jeder die komplette Liste herunterladen kann. So schützt du Dokumente pro Nutzer richtig:
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}Jeder Nutzer liest und schreibt nur sein eigenes Dokument. Für Daten, die mehrere teilen (ein Team, ein Projekt), speicherst du die Mitgliederliste im Dokument und prüfst sie in der Regel.
3. „Authentifiziert" mit „autorisiert" verwechseln
Die Regel allow read: if request.auth != null sieht sicher aus und ist der häufigste Fehler. Sie sagt: Jeder eingeloggte Nutzer darf lesen. Aber sich bei deiner App zu registrieren ist kostenlos und dauert zehn Sekunden, also ist es praktisch dasselbe wie offen. Authentifiziert beantwortet wer du bist; autorisiert was du sehen darfst. Die Regeln müssen Letzteres beantworten.
4. Sensible Daten in lesbaren Dokumenten
Ein öffentliches Profil mit Name und Avatar ist vernünftig. Dasselbe Dokument mit E-Mail, Telefon, Adresse und einem Zugriffstoken nicht. Wenn andere Nutzer einen Teil des Profils sehen können müssen, trenne Öffentliches von Privatem in zwei Dokumente oder eine Subcollection private mit strengeren Regeln. Was nicht in einem lesbaren Dokument steht, kann nicht leaken.
5. Glauben, die Firebase-Konfiguration sei ein Geheimnis
Das Objekt mit apiKey, authDomain und projectId geht absichtlich in den Browser: Es identifiziert dein Projekt, es autorisiert nichts. Es im Quelltext zu sehen ist kein Fehler, und es ist nicht das, was du verstecken musst. Was du mit diesem Schlüssel tun solltest: ihn in der Google-Cloud-Konsole auf die Domains deiner Website beschränken (Einschränkung nach HTTP-Referrer) und App Check aktivieren, das verlangt, dass Anfragen aus deiner echten App kommen und nicht aus einem Skript.
6. Andere Schlüssel sind sehr wohl geheim
Der schwere Fehler ist ein anderer: Neben der Firebase-Konfiguration trägt das Bundle den geheimen Stripe-Schlüssel, den von OpenAI oder den eines E-Mail-Dienstes, weil „es so einfacher war". Diese Schlüssel geben Zugriff auf Geld und Drittkonten. Ihr Platz ist eine Cloud Function mit den Geheimnissen in Umgebungsvariablen, und der Browser ruft die Function auf, nie den Dienst direkt. Die Details stehen in Geheimnisse, die deine App im Browser preisgibt.
7. Storage ohne eigene Regeln
Cloud Storage hat eigene Regeln, und die werden oft vergessen. Mit allow read, write: if request.auth != null kann jeder registrierte Nutzer die Dateien der anderen lesen, beliebiges Zeug auf beliebige Pfade hochladen und dein Kontingent füllen. Eine vernünftige Regel beschränkt den Pfad auf den Nutzer und validiert Größe und Typ:
match /users/{userId}/{fileName} {
allow read: if request.auth != null && request.auth.uid == userId;
allow write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}8. Offene Realtime Database
Wenn du die Realtime Database statt Firestore nutzt, ist das Äquivalent ".read": true im Root. Die Regeln sind eine andere Sprache, aber die Logik ist dieselbe: nichts offen im Root, und Berechtigungen pro Zweig mit auth.uid.
9. Schreiben ohne Validierung
Dem Besitzer des Dokuments Schreibrechte zu geben reicht nicht, wenn du nicht validierst, was er schreibt. Ein Nutzer kann aus der Browser-Konsole isAdmin: true oder plan: "pro" in sein eigenes Profil schreiben. Validiere die Felder mit request.resource.data: welche Schlüssel existieren, welchen Typ sie haben und dass sensible Felder sich nicht ändern.
allow update: if request.auth.uid == userId
&& !request.resource.data.diff(resource.data).affectedKeys()
.hasAny(['isAdmin', 'plan', 'credits']);10. Die Rechnung vergessen
Firebase rechnet pro Lesevorgang ab. Eine Regel, die list ohne Limit auf einer großen Collection erlaubt, lässt ein Skript Millionen Dokumente lesen und dir eine unerwartete Rechnung bescheren. Begrenze Abfragen über die Regeln (request.query.limit <= 100), aktiviere App Check und richte Budget-Alarme in Google Cloud ein.
Wie du es selbst prüfst
- Regel-Simulator. In der Firebase-Konsole, Tab Regeln, gibt es einen Simulator, in dem du einen Lesezugriff als anonymer Nutzer oder mit einer bestimmten UID testest. Versuch,
usersohne Sitzung zu lesen: Es muss abgelehnt werden. - Emulator mit Tests. Der lokale Emulator erlaubt automatisierte Regel-Tests. Das ist der einzige Weg, sie beim Ändern nicht kaputtzumachen.
- Von außen, ohne Token. Die REST-API von Firestore antwortet jedem:
curl "https://firestore.googleapis.com/v1/projects/DEIN_PROJEKT/databases/(default)/documents/users"Liefert sie Dokumente, ist diese Collection offen. Liefert sie einen Berechtigungsfehler, funktioniert die Regel. Wiederhole das für jede Collection, die du hast.
Scanaris prüft dein Firebase von außen
Scanaris erkennt die Firebase-Konfiguration in deinem Bundle, prüft, ob die üblichen Collections ohne Authentifizierung antworten, sucht nach weiteren Schlüsseln, die nicht in den Browser gehören, und prüft Header, CORS und offengelegte Dateien. Für jeden Fund bekommst du einen Fix-Prompt mit der exakten Regel oder Änderung zum Einfügen in Lovable, Bolt oder Cursor. Das sind reine Lesezugriffe auf das, was schon öffentlich ist. Die vollständige Risikoliste steht im Sicherheits-Guide für Firebase, und vor dem Launch lohnt sich die Sicherheits-Checkliste.
Häufige Fragen
Ist es ein Problem, dass mein Firebase-apiKey im Code steht?
Nicht an sich: Er identifiziert das Projekt, er gibt keine Berechtigungen. Was die Daten schützt, sind die Regeln. Trotzdem: Beschränke den Schlüssel auf deine Domains und aktiviere App Check, um Missbrauch zu verhindern.
Was tue ich, wenn meine Regeln gerade jetzt offen sind?
Erst schließen: Setz Regeln pro Collection mit request.auth.uid, auch wenn eine Funktion dadurch ausfällt, und repariere die App danach. Dann prüf in den Nutzungsprotokollen, ob es auffällige Lesezugriffe gab, und wenn personenbezogene Daten offenlagen, überleg, ob du es melden musst.
Kann ich meine KI bitten, die Regeln zu schreiben?
Ja, und sie macht das meist gut, wenn du ihr die Struktur deiner Collections gibst und wer was sehen soll. Aber teste sie im Simulator, bevor du veröffentlichst: Auch eine KI schreibt if request.auth != null im Glauben, das sei sicher.