Grundlegende Sicherheitsregeln

Mit Firebase-Sicherheitsregeln können Sie den Zugriff auf Ihre gespeicherten Daten kontrollieren. Die flexible Regelsyntax bedeutet, dass Sie Regeln erstellen können, die mit allem übereinstimmen, von allen Schreibvorgängen in die gesamte Datenbank bis hin zu Operationen in einem bestimmten Dokument.

Dieser Leitfaden beschreibt einige der grundlegenderen Anwendungsfälle, die Sie möglicherweise implementieren möchten, wenn Sie Ihre App einrichten und Ihre Daten schützen. Bevor Sie jedoch mit dem Schreiben von Regeln beginnen, möchten Sie vielleicht mehr über die Sprache, in der sie geschrieben sind, und ihr Verhalten erfahren.

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

Standardregeln: Gesperrter Modus

Wenn Sie eine Datenbank- oder Speicherinstanz in der Firebase-Konsole erstellen, wählen Sie aus, ob Ihre Firebase-Sicherheitsregeln den Zugriff auf Ihre Daten einschränken ( Sperrmodus ) oder allen Zugriff gewähren ( Testmodus ). In Cloud Firestore und Realtime Database verweigern die Standardregeln für den Sperrmodus 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 der Entwicklungsumgebung

Während Sie an Ihrer App arbeiten, möchten Sie möglicherweise einen relativ offenen oder uneingeschränkten Zugriff auf Ihre Daten. Stellen Sie nur sicher, dass Sie Ihre Regeln aktualisieren, bevor Sie Ihre App in der Produktion bereitstellen. Denken Sie auch daran, dass Ihre Anwendung ö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 vor allem verlassen Sie sich nicht auf einen zwischengeschalteten Server, um Daten vor der Welt zu schützen.

Alle authentifizierten Benutzer

Obwohl wir nicht empfehlen, Ihre Daten jedem angemeldeten Benutzer zugänglich zu machen, kann es hilfreich sein, den Zugriff auf 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 einen benutzerbasierten Zugriff einzurichten, und lesen Sie direkt aus Ihrer Datenbank, um einen datenbasierten Zugriff einzurichten.

Erwägen Sie das Schreiben von Regeln, wenn Sie Ihre Daten strukturieren, da die Art und Weise, wie Sie Ihre Regeln einrichten, sich darauf auswirkt, wie Sie den Zugriff auf Daten auf verschiedenen Pfaden einschränken.

Zugriff nur für Inhaltseigentümer

Diese Regeln beschränken den Zugriff nur auf den authentifizierten Eigentümer des Inhalts. Die Daten können nur von einem Benutzer gelesen und geschrieben werden, und der Datenpfad enthält die ID des Benutzers.

Wann diese Regel funktioniert: Diese Regel funktioniert gut, wenn Daten vom Benutzer isoliert werden – 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, dem diese Daten gehören.

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 ermöglicht es 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.

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

Wenn diese Regel nicht funktioniert: Wie die Regel nur für den Inhaltseigentümer funktioniert dieser Regelsatz nicht, wenn mehrere Benutzer dieselben Daten bearbeiten müssen. Die Benutzer werden letztendlich die Daten des anderen überschreiben.

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 Regeln funktionieren, müssen Sie Benutzern in Ihren Daten Attribute definieren und diese zuweisen. Firebase-Sicherheitsregeln prüfen die Anfrage anhand der Daten aus Ihrer Datenbank oder den Metadaten der Datei, um den Zugriff zu bestätigen oder zu verweigern.

Wenn diese Regel funktioniert: Wenn Sie Benutzern eine Rolle zuweisen, erleichtert diese Regel das Einschränken des Zugriffs basierend auf Rollen oder bestimmten Benutzergruppen. Wenn Sie beispielsweise Noten speichern, könnten Sie der Gruppe „Studenten“ (nur ihre Inhalte lesen), der Gruppe „Lehrer“ (lesen und schreiben in ihrem Fach) und der Gruppe „Schulleiter“ (lesen Alle Inhalte).

Wenn diese Regel nicht funktioniert: In Realtime Database und Cloud Storage können Ihre Regeln die get() Methode nicht nutzen, die Cloud Firestore-Regeln integrieren können. 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 der Zugriff bedingt gewährt wird. Erstellen Sie in Realtime Database 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 beliebigen 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 die Mandantenfähigkeit in Google Cloud Identity Platform (GCIP) ein und nutzen Sie dann den Mandanten in Ihren Regeln. Die folgenden Beispiele erlauben 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;
  }
}