Grundlegende Sicherheitsregeln

Mit Firebase-Sicherheitsregeln können Sie den Zugriff auf Ihre gespeicherten Daten steuern. Dank der flexiblen Regelsyntax können Sie Regeln erstellen, die alles abdecken, von allen Schreibvorgängen in der gesamten Datenbank bis hin zu Vorgängen an einem bestimmten Dokument.

In diesem Leitfaden werden einige der grundlegenderen Anwendungsfälle beschrieben, die Sie beim Einrichten Ihrer App und beim Schutz Ihrer Daten möglicherweise implementieren möchten. Bevor Sie jedoch mit dem Schreiben von Regeln beginnen, möchten Sie möglicherweise mehr über die Sprache, in der sie geschrieben sind, und ihr Verhalten erfahren.

Um auf Ihre Regeln zuzugreifen und diese zu aktualisieren, befolgen Sie die unter Verwalten und Bereitstellen von Firebase-Sicherheitsregeln beschriebenen Schritte.

Standardregeln: Gesperrter Modus

Wenn Sie in der Firebase-Konsole eine Datenbank oder Speicherinstanz erstellen, wählen Sie aus, ob Ihre Firebase-Sicherheitsregeln den Zugriff auf Ihre Daten einschränken ( Gesperrter Modus ) oder jedem den Zugriff erlauben ( Testmodus ). In Cloud Firestore und Realtime Database verweigern die Standardregeln für den gesperrten Modus allen Benutzern den Zugriff. In Cloud Storage können nur authentifizierte Benutzer auf die Speicher-Buckets zugreifen.

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

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

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

Regeln für die Entwicklungsumgebung

Während Sie an Ihrer App arbeiten, möchten Sie möglicherweise einen relativ offenen oder uneingeschränkten Zugriff auf Ihre Daten. Aktualisieren Sie unbedingt Ihre Regeln, bevor Sie Ihre App in der Produktion bereitstellen. Denken Sie auch daran, dass Ihre App öffentlich zugänglich ist, wenn Sie sie bereitstellen – auch wenn Sie sie nicht gestartet haben.

Denken Sie daran, dass Firebase Clients direkten Zugriff auf Ihre Daten ermöglicht und Firebase-Sicherheitsregeln die einzige Schutzmaßnahme sind, die den Zugriff für böswillige Benutzer blockiert. Das Definieren von Regeln getrennt von der Produktlogik hat eine Reihe von Vorteilen: Clients sind nicht für die Durchsetzung der Sicherheit verantwortlich, fehlerhafte Implementierungen gefährden Ihre Daten nicht und, was am wichtigsten ist, Sie sind nicht auf einen Zwischenserver angewiesen, um Daten vor der Welt zu schützen.

Alle authentifizierten Benutzer

Wir empfehlen zwar nicht, Ihre Daten jedem angemeldeten Benutzer zugänglich zu machen, es kann jedoch sinnvoll sein, den Zugriff für jeden authentifizierten Benutzer festzulegen, während Sie Ihre App entwickeln.

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

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

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

Produktionsreife Regeln

Stellen Sie bei der Vorbereitung der Bereitstellung Ihrer App sicher, dass Ihre Daten geschützt sind und Ihren Benutzern ordnungsgemäß Zugriff gewährt wird. Nutzen Sie die Authentifizierung , um benutzerbasierten Zugriff einzurichten, und lesen Sie direkt aus Ihrer Datenbank, um datenbasierten Zugriff einzurichten.

Erwägen Sie beim Strukturieren Ihrer Daten das Schreiben von Regeln, da die Art und Weise, wie Sie Ihre Regeln einrichten, Auswirkungen darauf hat, wie Sie den Zugriff auf Daten auf verschiedenen Pfaden einschränken.

Zugriff nur für den Inhaltseigentümer

Diese Regeln beschränken den Zugriff nur auf den authentifizierten Eigentümer des Inhalts. Die Daten sind nur für einen Benutzer les- und schreibbar und der Datenpfad enthält die Benutzer-ID.

Wenn diese Regel funktioniert: Diese Regel funktioniert gut, wenn Daten nach Benutzern isoliert sind – wenn der einzige Benutzer, der auf die Daten zugreifen muss, derselbe Benutzer ist, der die Daten erstellt hat.

Wenn diese Regel nicht funktioniert: Dieser Regelsatz funktioniert nicht, wenn mehrere Benutzer dieselben Daten schreiben oder lesen müssen – Benutzer überschreiben Daten oder können nicht auf die von ihnen erstellten Daten zugreifen.

So richten Sie diese Regel ein: Erstellen Sie eine Regel, die bestätigt, dass der Benutzer, der Zugriff zum Lesen oder Schreiben von Daten anfordert, der Benutzer ist, der Eigentümer dieser Daten ist.

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

{
  "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"
      }
    }
  }
}

// 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 != null && request.auth.uid == userId;
    }
  }
}

Gemischter öffentlicher und privater Zugang

Diese Regel erlaubt jedem, einen Datensatz zu lesen, beschränkt jedoch die Möglichkeit, Daten in einem bestimmten Pfad zu erstellen oder zu ändern, nur auf den authentifizierten Inhaltseigentümer.

Wenn diese Regel funktioniert: Diese Regel funktioniert gut für Apps, die öffentlich lesbare Elemente erfordern, aber den Bearbeitungszugriff auf die Besitzer dieser Elemente beschränken müssen. Zum Beispiel eine Chat-App oder ein Blog.

Wenn diese Regel nicht funktioniert: Wie die Regel „Nur Inhaltseigentümer“ funktioniert dieser Regelsatz nicht, wenn mehrere Benutzer dieselben Daten bearbeiten müssen. Letztendlich überschreiben Benutzer ihre Daten gegenseitig.

So richten Sie diese Regel ein: Erstellen Sie eine Regel, die Lesezugriff für alle Benutzer (oder alle authentifizierten Benutzer) ermöglicht und bestätigt, dass der Benutzer, der Daten schreibt, der Eigentümer ist.

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 create: if request.auth.uid == request.resource.data.author_uid;
      allow update, delete: if request.auth.uid == resource.data.author_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"
      }
    }
  }
}

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

Attributbasierter und rollenbasierter Zugriff

Damit diese Regel funktioniert, müssen Sie in Ihren Daten Attribute definieren und den Benutzern zuweisen. Firebase-Sicherheitsregeln vergleichen die Anfrage mit den Daten aus Ihrer Datenbank oder den Metadaten Ihrer Datei, um den Zugriff zu bestätigen oder zu verweigern.

Wenn diese Regel funktioniert: Wenn Sie Benutzern eine Rolle zuweisen, erleichtert diese Regel die Zugriffsbeschränkung basierend auf Rollen oder bestimmten Benutzergruppen. Wenn Sie beispielsweise Noten speichern, können Sie der Gruppe „Schüler“ (nur Lesen ihrer Inhalte), der Gruppe „Lehrer“ (Lesen und Schreiben in ihrem Fach) und der Gruppe „Schulleiter“ (Lesen) unterschiedliche Zugriffsebenen zuweisen Alle Inhalte).

Wenn diese Regel nicht funktioniert: In Realtime Database und Cloud Storage können Ihre Regeln die get() Methode, die Cloud Firestore-Regeln integrieren können, nicht nutzen. Folglich müssen Sie Ihre Datenbank- oder Dateimetadaten so strukturieren, dass sie die Attribute widerspiegeln, die Sie in Ihren Regeln verwenden.

So richten Sie diese Regel ein: Fügen Sie in Cloud Firestore ein Feld in die Dokumente Ihrer Benutzer ein, das Sie lesen können, und strukturieren Sie dann Ihre Regel so, dass dieses Feld gelesen und bedingt Zugriff gewährt wird. Erstellen Sie in der Echtzeitdatenbank einen Datenpfad, der die Benutzer Ihrer App definiert und ihnen eine Rolle in einem untergeordneten Knoten zuweist.

Sie können auch benutzerdefinierte Ansprüche in der Authentifizierung einrichten und diese Informationen dann aus der Variablen auth.token in allen Firebase-Sicherheitsregeln abrufen.

Datendefinierte Attribute und Rollen

Diese Regeln funktionieren nur in Cloud Firestore und Realtime Database.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, Check a boolean `admin` attribute
    allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    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"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

Benutzerdefinierte Anspruchsattribute und -rollen

Um diese Regeln zu implementieren, richten Sie benutzerdefinierte Ansprüche in Firebase Authentication ein und nutzen Sie dann die Ansprüche in Ihren Regeln.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to leverage
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

service firebase.storage {
  // 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;
  }
}

Mietattribute

Um diese Regeln zu implementieren, richten Sie Mehrmandantenfähigkeit in der Google Cloud Identity Platform (GCIP) ein und nutzen Sie dann den Mandanten in Ihren Regeln. Die folgenden Beispiele ermöglichen Schreibvorgänge von einem Benutzer in einem bestimmten Mandanten, z. B. tenant2-m6tyz

service cloud.firestore {
  match /databases/{database}/documents {
    // For tenant-based access control, check for a tenantID
    allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
    allow read: true;
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Only allow reads and writes if user belongs to a specific tenant
        ".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
        ".read": "auth.uid !== null
      }
    }
  }
}

service firebase.storage {
  // Only allow reads and writes if user belongs to a specific tenant
  match /files/{tenantId}/{fileName} {
    allow read: if request.auth != null;
    allow write: if request.auth.token.firebase.tenant == tenantId;
  }
}