Firebase ist bequem, weil es deine App ohne Backend an eine Datenbank anbindet, aber diese Bequemlichkeit ist auch die Falle: die Sicherheit hängt fast vollständig von den Regeln ab, die du schreibst. Das sind die Fehler, die am häufigsten vorkommen.
Die Regeln im Testmodus lassen
Wenn du Firestore oder die Realtime Database anlegst, bietet Firebase einen Testmodus an, der eine Zeit lang jedem Lesen und Schreiben erlaubt. Das ist praktisch zum Start, aber viele Leute gehen mit diesen Regeln live. Das Ergebnis: jeder kann deine gesamte Datenbank aus der Browser-Konsole lesen und ändern.
Ändere die Regeln vor dem Start so, dass sie eine Authentifizierung verlangen und jeden Nutzer auf seine eigenen Daten beschränken.
Den öffentlichen Schlüssel mit Sicherheit verwechseln
Die Firebase-Konfiguration, die du ins Frontend einfügst (apiKey, projectId usw.), ist absichtlich öffentlich und kein Geheimnis. Das verwirrt viele: sie nehmen an, dass Google sie schützt, weil sie im Client lebt. Das tut es nicht. Was deine Daten schützt, sind die Sicherheitsregeln, nicht das Verstecken dieses Schlüssels. Das Gegenteil anzunehmen führt zu offenen Datenbanken.
Regeln, die alles lesen erlauben
Eine Regel wie allow read: if true lässt deine Collections für jeden offen. Der klassische Fehler ist, die Regeln zu lockern, bis die App keine Fehler mehr wirft, und sie nie wieder anzuziehen. Schreibe Regeln pro Collection: prüfe request.auth und vergleiche den Nutzer mit dem Dokument-Eigentümer.
Sensible Daten in lesbaren Dokumenten
Selbst wenn du ein Login verlangst, prüfe, was du speicherst. E-Mails, Admin-Rollen oder interne Flags in Dokumenten, die jeder authentifizierte Nutzer lesen kann, sind trotzdem ein Leck. Trenne Privates in Collections mit strengeren Regeln und nimm nicht an, dass niemand nachschaut.
Andere im Bundle versteckte Schlüssel
Die Firebase-Konfiguration ist öffentlich, reist aber meist mit anderen Schlüsseln, die es nicht sind: Tokens für Zahlungs-, E-Mail- oder KI-Dienste. Die sind geheim und dürfen nicht im Browser-JavaScript landen. Die KI baut sie manchmal ein, um etwas auf die Schnelle zum Laufen zu bringen.
Scanaris entdeckt, was exponiert wurde
Scanaris führt reine Lese-Prüfungen gegen deine veröffentlichte Website aus: es sucht nach im Frontend exponierten Schlüsseln und Secrets, erreichbaren sensiblen Dateien und schwachen Header-Einstellungen. Es nutzt nichts aus; es sieht nur, was ohnehin öffentlich ist, und warnt dich. Jeder Fund kommt mit einem Prompt, um ihn in deiner KI zu beheben. Scanne deine App, bevor es jemand anderes tut.