Grundlegende Sicherheitsregeln

Firebase Security Rules ermöglichen Ihnen die Steuerung des Zugriffs auf Ihre gespeicherten Daten. Dank der flexiblen Regelsyntax können Sie Regeln für beliebige Bereiche erstellen – von sämtlichen Schreibvorgängen über die gesamte Datenbank bis hin zu Vorgängen in einem bestimmten Dokument.

In dieser Anleitung werden einige der grundlegenderen Anwendungsfälle beschrieben, die Sie bei der Einrichtung Ihrer App und dem Schutz Ihrer Daten implementieren können. Bevor Sie jedoch mit dem Schreiben von Regeln beginnen, sollten Sie mehr über die Sprache, in der sie geschrieben sind, und ihr Verhalten erfahren.

Informationen zum Zugriff auf Ihre Regeln und zum Aktualisieren Ihrer Regeln finden Sie unter Firebase-Sicherheitsregeln verwalten und bereitstellenFirebase Security Rules.

Standardregeln: Sperrmodus

Wenn Sie in der Firebase Console eine Datenbank- oder Speicherinstanz erstellen, wählen Sie aus, ob Ihre Firebase Security Rules den Zugriff auf Ihre Daten einschränken (Sperrmodus) oder allen Zugriff gewähren (Testmodus). In Cloud Firestore und Realtime Database, wird der Zugriff für alle Nutzer durch die Standardregeln für den Sperrmodus verweigert. In Cloud Storage können nur authentifizierte Nutzer auf die Speicher-Buckets zugreifen.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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

Regeln für die Entwicklungsumgebung

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

Firebase ermöglicht Clients den direkten Zugriff auf Ihre Daten. Firebase Security Rules sind die einzige Schutzmaßnahme, die den Zugriff für böswillige Nutzer blockiert. Die Definition 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 sind Sie nicht auf einen Vermittlungsserver angewiesen, um Daten vor der Außenwelt zu schützen.

Alle authentifizierten Nutzer

Wir empfehlen zwar nicht, Ihre Daten für alle angemeldeten Nutzer zugänglich zu machen, es kann jedoch nützlich sein, den Zugriff für alle authentifizierten Nutzer festzulegen, während Sie Ihre App entwickeln.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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

Produktionsreife Regeln

Wenn Sie Ihre App bereitstellen möchten, müssen Sie sicherstellen, dass Ihre Daten geschützt sind und dass Ihren Nutzern der Zugriff ordnungsgemäß gewährt wird. Verwenden Sie Authentication, um den nutzerbasierten Zugriff einzurichten, und lesen Sie direkt aus Ihrer Datenbank, um den datenbasierten Zugriff einzurichten.

Sie sollten Regeln schreiben, während Sie Ihre Daten strukturieren, da sich die Art und Weise, wie Sie Ihre Regeln einrichten, auf die Einschränkung des Zugriffs auf Daten unter verschiedenen Pfaden auswirkt.

Zugriff nur für den Rechteinhaber

Diese Regeln beschränken den Zugriff nur auf den authentifizierten Rechteinhaber der Inhalte. Die Daten können nur von einem Nutzer gelesen und geschrieben werden und der Datenpfad enthält die Nutzer-ID.

Wann funktioniert diese Regel? Diese Regel eignet sich gut, wenn Daten nach Nutzer isoliert sind – wenn der einzige Nutzer, der auf die Daten zugreifen muss, derselbe Nutzer ist, der die Daten erstellt hat.

Wann funktioniert diese Regel nicht? Dieses Regelset funktioniert nicht, wenn mehrere Nutzer dieselben Daten lesen oder schreiben müssen. Nutzer überschreiben Daten oder können nicht auf von ihnen erstellte Daten zugreifen.

So richten Sie diese Regel ein:Erstellen Sie eine Regel, die bestätigt, dass der Nutzer, der Zugriff zum Lesen oder Schreiben von Daten anfordert, der Nutzer ist, dem diese Daten gehören.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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

Gemischter öffentlicher und privater Zugriff

Mit dieser Regel kann jeder ein Dataset lesen, aber die Möglichkeit, Daten unter einem bestimmten Pfad zu erstellen oder zu ändern, ist nur auf den authentifizierten Rechteinhaber der Inhalte beschränkt.

Wann funktioniert diese Regel? Diese Regel eignet sich gut für Apps, die öffentlich lesbare Elemente erfordern, aber den Bearbeitungszugriff auf die Rechteinhaber dieser Elemente beschränken müssen. Beispiele sind eine Chat-App oder ein Blog.

Wann funktioniert diese Regel nicht? Wie die Regel „Zugriff nur für den Rechteinhaber“ funktioniert dieses Regelset nicht, wenn mehrere Nutzer dieselben Daten bearbeiten müssen. Nutzer überschreiben letztendlich die Daten der anderen.

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

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

Realtime Database

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

Cloud Storage

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

Attributbasierter und rollenbasierter Zugriff

Damit diese Regel funktioniert, müssen Sie Attribute definieren und Nutzern in Ihren Daten zuweisen. Firebase Security Rules prüfen die Anfrage anhand der Daten aus Ihrer Datenbank oder der Metadaten der Datei , um den Zugriff zu bestätigen oder zu verweigern.

Wann funktioniert diese Regel? Wenn Sie Nutzern eine Rolle zuweisen, können Sie mit dieser Regel den Zugriff basierend auf Rollen oder bestimmten Nutzergruppen einschränken. Wenn Sie beispielsweise Noten speichern, können Sie der Gruppe „Schüler“ unterschiedliche Zugriffsebenen zuweisen (nur Inhalte lesen), der Gruppe „Lehrer“ (in ihrem Fach lesen und schreiben) und der Gruppe „Schulleiter“ (alle Inhalte lesen).

Wann funktioniert diese Regel nicht? In Realtime Database und Cloud Storage, können Ihre Regeln nicht die Methode get() verwenden, die in Cloud Firestore Regeln enthalten sein kann. Daher müssen Sie die Metadaten Ihrer Datenbank oder Datei 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 Nutzer 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 Nutzer Ihrer App definiert und ihnen eine Rolle in einem untergeordneten Knoten zuweist.

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

Datendefinierte Attribute und Rollen

Diese Regeln funktionieren nur in Cloud Firestore und Realtime Database.

Cloud Firestore

Beachten Sie, dass jedes Mal, wenn Ihre Regeln einen Lesevorgang enthalten, wie in den folgenden Regeln, Ihnen ein Lesevorgang in Cloud Firestore in Rechnung gestellt wird.

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

Realtime Database

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

Attribute und Rollen für benutzerdefinierte Ansprüche

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

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an administrator 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";
   }
  }
}

Realtime Database

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

Cloud Storage

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

Attribute für Mandantenfähigkeit

Um diese Regeln zu implementieren, richten Sie die Mehrinstanzenfähigkeit in Google Cloud Identity Platform (GCIP) ein und verwenden Sie dann den Mandanten in Ihren Regeln. In den folgenden Beispielen sind Schreibvorgänge von einem Nutzer in einem bestimmten Mandanten zulässig, z. B. tenant2-m6tyz.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

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