Firebase-Regeln offen: so macht ihr Firestore und Storage dicht

Woran ihr offene Regeln erkennt

Während der Entwicklung sind offene Regeln bequem. Laut Firebase-Doku müsst ihr sie aber vor dem Livegang anpassen. Steht in euren Regeln allow read, write: if true, darf jeder lesen und schreiben.

Die Doku ist deutlich: Firebase Security Rules sind bei direktem Zugriff aus dem Client die einzige Schutzschicht gegen böswillige Nutzer.

Mindestens: nur angemeldete Nutzer

Die einfachste Verschärfung lässt nur angemeldete Nutzer zu: allow read, write: if request.auth != null. Das schützt vor anonymen Besuchern, aber nicht davor, dass ein Nutzer Daten anderer Nutzer sieht.

Besser: nur der Besitzer

Für Daten, die einem Nutzer gehören, vergleicht die Regel die Nutzer-ID der Anfrage mit der ID im Pfad: allow read, write: if request.auth != null && request.auth.uid == userId, mit userId aus dem Pfad. In Firestore passt dazu zum Beispiel ein Dokumentpfad wie match /nutzer/{userId}. Bei Storage steht die ID im Dateipfad.

Gemischt: öffentlich lesen, nur Besitzer ändern

Inhalte, die jeder lesen darf, die aber nur ihr Autor ändern soll, bekommen getrennte Regeln: Lesen für alle, dazu je eine Regel für create, update und delete. Beim Anlegen (create) vergleicht ihr request.auth.uid mit der Autoren-ID in den neuen Daten (request.resource.data), beim Ändern (update) mit der Autoren-ID der bestehenden und der neuen Daten, damit niemand den Besitzer wechseln kann, und beim Löschen (delete) mit der bestehenden (resource.data).

Regeln vor dem Livegang testen

Mit der Firebase Local Emulator Suite lassen sich Security Rules lokal prüfen und Tests automatisieren, bevor ihr sie veröffentlicht.

Typische Fehler

Diese Fehler ergeben sich aus der Firebase-Doku:

• Die Regeln des Testmodus im Livebetrieb lassen. Im Testmodus darf laut Doku jeder auf die Daten zugreifen, deshalb gehören die Regeln vor dem Livegang angepasst.
• Sich darauf verlassen, dass die App schon prüft. Die Doku beschreibt es umgekehrt: Clients sind nicht für die Durchsetzung der Sicherheit zuständig, das übernehmen die Regeln.
• Nur request.auth != null verlangen, obwohl die Daten einzelnen Nutzern gehören. Dann sieht jeder angemeldete Nutzer die Daten aller anderen. Vergleicht in diesem Fall die Nutzer-ID.
• Regeln veröffentlichen, ohne sie vorher zu testen. Die Emulator Suite prüft sie lokal.

Beispiel: erst alles sperren, dann gezielt öffnen

Aus der Firebase-Doku: Die Standardregeln des gesperrten Modus verweigern in Cloud Firestore jeden Zugriff. Darauf baut ihr auf und erlaubt nur, was eure App braucht, zum Beispiel den Zugriff auf Dokumente eines Nutzers unter dessen eigener ID:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Häufige Fragen