Vermeiden Sie unsichere Regeln

Verwenden Sie diesen Leitfaden, um häufige Schwachstellen in Firebase-Sicherheitsregelkonfigurationen zu verstehen, Ihre eigenen Regeln zu überprüfen und besser zu sichern und Ihre Änderungen zu testen, bevor Sie sie bereitstellen.

Wenn Sie eine Warnung erhalten, dass Ihre Daten nicht ordnungsgemäß gesichert sind, überprüfen Sie diese häufig gemachten Fehler und aktualisieren Sie alle anfälligen Regeln.

Greifen Sie auf Ihre Firebase-Sicherheitsregeln zu

Um Ihre vorhandenen Regeln anzuzeigen, verwenden Sie entweder die Firebase-CLI oder die Firebase-Konsole. Stellen Sie sicher, dass Sie Ihre Regeln konsistent mit der gleichen Methode bearbeiten, um ein versehentliches Überschreiben von Aktualisierungen zu vermeiden. Wenn Sie nicht sicher sind, ob Ihre lokal definierten Regeln die neuesten Updates widerspiegeln, zeigt die Firebase-Konsole immer die zuletzt bereitgestellte Version Ihrer Firebase-Sicherheitsregeln an.

Um über die Firebase-Konsole auf Ihre Regeln zuzugreifen, wählen Sie Ihr Projekt aus und navigieren Sie dann zu Realtime Database , Cloud Firestore oder Storage . Klicken Sie auf Regeln , sobald Sie sich in der richtigen Datenbank oder im richtigen Speicher-Bucket befinden.

Um über die Firebase-CLI auf Ihre Regeln zuzugreifen, rufen Sie die in Ihrer Datei „firebase.json“ angegebene Regeldatei auf.

Verstehen Sie die Firebase-Sicherheitsregeln

Firebase-Sicherheitsregeln schützen Ihre Daten vor böswilligen Benutzern. Wenn Sie eine Datenbankinstanz oder einen Cloud Storage-Bucket in der Firebase-Konsole erstellen, können Sie entweder allen Benutzern den Zugriff verweigern ( Gesperrter Modus ) oder allen Benutzern Zugriff gewähren ( Testmodus ). Während Sie während der Entwicklung möglicherweise eine offenere Konfiguration wünschen, sollten Sie sich vor der Bereitstellung Ihrer App unbedingt die Zeit nehmen, Ihre Regeln ordnungsgemäß zu konfigurieren und Ihre Daten zu sichern.

Während Sie Ihre App entwickeln und verschiedene Konfigurationen für Ihre Regeln testen, verwenden Sie einen der lokalen Firebase-Emulatoren , um Ihre App in einer lokalen Entwicklungsumgebung auszuführen.

Häufige Szenarien mit unsicheren Regeln

Die Regeln, die Sie möglicherweise standardmäßig oder bei der anfänglichen Entwicklung Ihrer App eingerichtet haben, sollten überprüft und aktualisiert werden, bevor Sie Ihre App bereitstellen. Stellen Sie sicher, dass Sie die Daten Ihrer Benutzer ordnungsgemäß schützen, indem Sie die folgenden häufigen Fallstricke vermeiden.

Offener Zugang

Beim Einrichten Ihres Firebase-Projekts haben Sie möglicherweise Ihre Regeln so festgelegt, dass während der Entwicklung offener Zugriff möglich ist. Sie denken vielleicht, dass Sie die einzige Person sind, die Ihre App nutzt, aber wenn Sie sie bereitgestellt haben, ist sie im Internet verfügbar. Wenn Sie keine Benutzer authentifizieren und keine Sicherheitsregeln konfigurieren, kann jeder, der Ihre Projekt-ID errät, die Daten stehlen, ändern oder löschen.

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

  "rules": {
    ".read": true,
    ".write": true
  }
}
    

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded via App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write;
    }
  }
}
    

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      allow read, write: if request.auth != null && request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth != null && request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}
    

{
  // Allow anyone to read data, but only authenticated content owners can
  // make changes to their data

  "rules": {
    "some_path/$uid": {
      ".read": true,
      // or ".read": "auth.uid !== null" for only authenticated users
      ".write": "auth.uid === $uid"
    }
  }
}
    

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}
  

Zugriff für jeden authentifizierten Benutzer

Manchmal überprüfen Regeln, ob ein Benutzer angemeldet ist, schränken den Zugriff jedoch nicht weiter auf der Grundlage dieser Authentifizierung ein. Wenn eine Ihrer Regeln auth != null enthält, bestätigen Sie, dass jeder angemeldete Benutzer Zugriff auf die Daten haben soll.

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

{
  "rules": {
    ".read": "auth.uid !== null",
    ".write": "auth.uid !== null"
  }
}

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}
  

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      allow read: if true
      allow write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid"
      }
    }
  }
}
    

{
  "rules": {
    "some_path/$uid": {
      ".write": "auth.uid === $uid",
      // Create a "public" subpath in your dataset
      "public": {
        ".read": true
        // or ".read": "auth.uid !== null"
      },
      // Create a "private" subpath in your dataset
      "private": {
        ".read": "auth.uid === $uid"
      }
    }
  }
}
    

{
  // Allow anyone to read data, but only authenticated content owners can
  // make changes to their data

  "rules": {
    "some_path/$uid": {
      ".read": true,
      // or ".read": "auth.uid !== null" for only authenticated users
      ".write": "auth.uid === $uid"
    }
  }
}
    

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}
  

(Echtzeitdatenbank) Falsch übernommene Regeln

Echtzeit-Datenbanksicherheitsregeln kaskadieren, wobei Regeln auf flacheren, übergeordneten Pfaden Regeln auf tieferen, untergeordneten Knoten überschreiben. Denken Sie beim Schreiben einer Regel an einem untergeordneten Knoten daran, dass dieser nur zusätzliche Berechtigungen gewähren kann. Sie können den Zugriff auf Daten in einem tieferen Pfad in Ihrer Datenbank nicht verfeinern oder widerrufen.

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

Geschlossener Zugang

Während Sie Ihre App entwickeln, besteht ein weiterer gängiger Ansatz darin, Ihre Daten gesperrt zu halten. Normalerweise bedeutet dies, dass Sie den Lese- und Schreibzugriff für alle Benutzer wie folgt gesperrt haben:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

{
  "rules": {
    ".read": false,
    ".write": false
  }
}
    

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

Die Firebase Admin SDKs und Cloud Functions können weiterhin auf Ihre Datenbank zugreifen. Verwenden Sie diese Regeln, wenn Sie Cloud Firestore oder Realtime Database als reines Server-Backend in Verbindung mit dem Firebase Admin SDK verwenden möchten. Obwohl es sicher ist, sollten Sie testen, ob die Clients Ihrer App Daten ordnungsgemäß abrufen können.

Weitere Informationen zu Cloud Firestore-Sicherheitsregeln und ihrer Funktionsweise finden Sie unter „Erste Schritte mit Cloud Firestore-Sicherheitsregeln“ .

Testen Sie Ihre Cloud Firestore-Sicherheitsregeln

Um das Verhalten Ihrer App zu überprüfen und Ihre Cloud Firestore-Sicherheitsregelkonfigurationen zu überprüfen, verwenden Sie den Firebase-Emulator . Verwenden Sie den Cloud Firestore-Emulator, um Komponententests in einer lokalen Umgebung auszuführen und zu automatisieren, bevor Sie Änderungen bereitstellen.

Um Firebase-Sicherheitsregeln in der Firebase-Konsole schnell zu validieren, verwenden Sie den Firebase-Regelsimulator .