Vermeiden Sie unsichere Regeln

Verwenden Sie diesen Leitfaden, um allgemeine 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 auftretenden Fehler und aktualisieren Sie alle gefährdeten Regeln.

Greifen Sie auf Ihre Firebase-Sicherheitsregeln zu

Verwenden Sie zum Anzeigen Ihrer vorhandenen Regeln entweder die Firebase-Befehlszeilenschnittstelle oder die Firebase-Konsole. Stellen Sie sicher, dass Sie Ihre Regeln immer mit der gleichen Methode bearbeiten, um ein versehentliches Überschreiben von Aktualisierungen zu vermeiden. Wenn Sie sich 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 Storage-Bucket befinden.

Um über die Firebase-CLI auf Ihre Regeln zuzugreifen, gehen Sie zu der Datei rules, die in Ihrer Datei firebase.json angegeben ist .

Machen Sie sich mit den Firebase-Sicherheitsregeln vertraut

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 ( Sperrmodus ) oder allen Benutzern Zugriff gewähren ( Testmodus ). Auch wenn Sie während der Entwicklung eine offenere Konfiguration wünschen, sollten Sie sich die Zeit nehmen, Ihre Regeln richtig zu konfigurieren und Ihre Daten zu sichern, bevor Sie Ihre App bereitstellen.

Wenn 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äß sichern, indem Sie die folgenden häufigen Fallstricke vermeiden.

Offener Zugang

Beim Einrichten Ihres Firebase-Projekts haben Sie möglicherweise Ihre Regeln festgelegt, um den offenen Zugriff während der Entwicklung zuzulassen. Sie denken vielleicht, dass Sie die einzige Person sind, die Ihre App verwendet, 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 basierend auf dieser Authentifizierung nicht weiter ein. Wenn eine Ihrer Regeln auth != null enthält, bestätigen Sie, dass alle angemeldeten Benutzer Zugriff auf die Daten haben sollen.

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;
    }
  }
}
  

(Realtime Database) Falsch vererbte Regeln

Echtzeit-Datenbank-Sicherheitsregeln kaskadieren, wobei Regeln an flacheren, übergeordneten Pfaden Regeln an tieferen, untergeordneten Knoten außer Kraft setzen. Wenn Sie eine Regel für einen untergeordneten Knoten schreiben, denken Sie daran, dass sie 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 zu sperren. 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 beabsichtigen, Cloud Firestore oder Realtime Database als Nur-Server-Back-End in Verbindung mit dem Firebase Admin SDK zu verwenden. Obwohl es sicher ist, sollten Sie testen, ob die Clients Ihrer App Daten ordnungsgemäß abrufen können.

Erfahren Sie mehr über Cloud Firestore-Sicherheitsregeln und ihre Funktionsweise in Erste Schritte mit Cloud Firestore-Sicherheitsregeln .

Testen Sie Ihre Cloud Firestore-Sicherheitsregeln

Verwenden Sie den Firebase-Emulator , um das Verhalten Ihrer App zu überprüfen und die Konfigurationen Ihrer Cloud Firestore-Sicherheitsregeln zu überprüfen. 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 .