Mit Firebase Security Rules können Sie den Zugriff auf Ihre gespeicherten Daten steuern. Die flexiblen Regeln Syntax bedeutet, dass Sie Regeln erstellen können, die alles übereinstimmen, von Schreibvorgängen bis hin zur der gesamten Datenbank bis hin zu Vorgängen in einem bestimmten Dokument.
In diesem Leitfaden werden einige der grundlegenderen Anwendungsfälle beschrieben, die Sie beim Einrichten Ihrer App und beim Schutz Ihrer Daten implementieren können. Bevor Sie jedoch sollten Sie zunächst Regeln aufstellen, Sprache und Verhalten.
Wenn Sie auf Ihre Regeln zugreifen und sie aktualisieren möchten, folgen Sie der Anleitung unter Firebase Security Rules verwalten und bereitstellen.
Standardregeln: Sperrmodus
Wenn Sie eine Datenbank oder Speicherinstanz in der Firebase-Konsole erstellen, Sie wählen aus, ob Ihr Firebase Security Rules den Zugriff auf Ihre Daten einschränken soll (Sperrmodus) oder allen Zugriff gewähren (Testmodus). In Cloud Firestore und Realtime Database, die Standardregeln für den Sperrmodus verweigern allen Nutzern den Zugriff. In Cloud Storage können nur authentifizierte Nutzer auf die Storage-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 request.auth != null;
}
}
}
Regeln für Entwicklungsumgebungen
Während Sie an Ihrer App arbeiten, können Sie diese relativ offen oder uneingeschränkt bearbeiten. auf Ihre Daten zugreifen können. Aktualisieren Sie einfach Ihr Gerät (Rules) vor dem stellen Sie die Anwendung für die Produktion bereit. Denken Sie auch daran, dass Ihre App nach der Bereitstellung öffentlich zugänglich ist, auch wenn Sie sie noch nicht veröffentlicht haben.
Denken Sie daran, dass Firebase Clients direkten Zugriff auf Ihre Daten ermöglicht. Firebase Security Rules sind die einzige Sicherheitsmaßnahme, die den Zugriff böswilliger Nutzer blockiert. Definition getrennt von der Produktlogik eine Reihe von Vorteilen bietet: für die Durchsetzung der Sicherheitsstandards verantwortlich, und, was am wichtigsten ist, nicht auf einen zwischengeschalteten Server angewiesen sind, um Daten vor der Welt zu schützen.
Alle authentifizierten Nutzer
Wir empfehlen zwar nicht, Ihre Daten für alle angemeldeten Nutzer zugänglich zu machen, es kann aber hilfreich 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 /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Realtime Database
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Cloud Storage
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Produktionsfertige Regeln
Achten Sie bei der Vorbereitung der Bereitstellung Ihrer App darauf, dass Ihre Daten geschützt sind und dass Ihren Nutzern der Zugriff ordnungsgemäß gewährt wird. Hebel Authentication zum Einrichten des nutzerbasierten Zugriffs und Lesezugriff aus Ihrer Datenbank, um den datenbasierten Zugriff einzurichten.
Überlegen Sie, bei der Strukturierung Ihrer Daten Regeln zu formulieren, wie Sie den Zugriff auf Daten auf verschiedenen Pfade.
Zugriff nur für Rechteinhaber
Diese Regeln beschränken den Zugriff ausschließlich auf den authentifizierten Inhaber der Inhalte. Die Daten nur von einem Nutzer lesbar und beschreibbar sind und der Datenpfad die ID des Nutzers.
Wann diese Regel funktioniert:Diese Regel funktioniert gut, wenn die Daten nach Nutzer*innen isoliert sind – wenn der einzige Nutzer, der auf die Daten zugreifen muss, der Nutzer ist, der die Daten.
Wenn diese Regel nicht funktioniert:Dieser Regelsatz funktioniert nicht, wenn mehrere Nutzer dieselben Daten schreiben oder lesen müssen – Nutzer überschreiben Daten um auf die von ihr erstellten Daten zuzugreifen.
So richten Sie diese Regel ein: Erstellen Sie eine Regel, die bestätigt, dass der Nutzer, der den Zugriff zum Lesen oder Schreiben von Daten anfordert, der Inhaber dieser Daten ist.
Cloud Firestore
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
}
}
}
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>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Gemischter öffentlicher und privater Zugriff
Mit dieser Regel kann jeder einen Datensatz lesen, aber nur der authentifizierte Rechteinhaber kann Daten an einem bestimmten Pfad erstellen oder ändern.
Wann diese Regel funktioniert:Diese Regel funktioniert gut bei Apps, die öffentlich zugänglich sind. lesbaren Elementen, müssen aber den Bearbeitungszugriff auf diese Elemente einschränken. Verantwortlichen. z. B. eine Chat-App oder ein Blog.
Wann diese Regel nicht funktioniert: Wie bei der Regel „Nur Rechteinhaber“ funktioniert diese Regel nicht, wenn mehrere Nutzer dieselben Daten bearbeiten müssen. Die Nutzenden die Daten letztendlich gegenseitig überschreiben.
So richten Sie diese Regel ein:Erstellen Sie eine Regel, die den Lesezugriff für alle Nutzer aktiviert (oder alle authentifizierten Nutzer) und bestätigt, dass der Nutzer, der Daten schreibt, der Eigentümer 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 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;
}
}
}
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>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read;
allow write: if request.auth.uid == userId;
}
}
}
Attribut- und rollenbasierter Zugriff
Damit diese Regel funktioniert, müssen Sie Nutzern in Ihren Daten Attribute definieren und zuweisen. Firebase Security Rules prüft die Anfrage mit den Daten aus Ihrer Datenbank oder den Dateien um den Zugriff zu bestätigen oder zu verweigern.
Wenn diese Regel funktioniert:Wenn Sie Nutzern eine Rolle zuweisen, bewirkt diese Regel können Sie den Zugriff einfach auf Basis von Rollen oder bestimmten Nutzergruppen einschränken. Wenn Sie beispielsweise Noten speichern, können Sie der Gruppe „Schüler“ (nur Inhalte lesen), der Gruppe „Lehrkräfte“ (Lesen und Schreiben im Fach) und der Gruppe „Leiter“ (alle Inhalte lesen) unterschiedliche Zugriffsebenen zuweisen.
Falls diese Regel nicht funktioniert:In Realtime Database und Cloud Storage werden Ihre Regeln
die Methode get(), die Cloud Firestore-Regeln enthalten können, nicht nutzen kann.
Daher müssen Sie Ihre Datenbank oder Dateimetadaten so strukturieren,
die Sie in Ihren Regeln verwenden.
So richten Sie diese Regel ein:Fügen Sie in Cloud Firestore ein Feld in das Feld Dokumente, die Sie lesen können, und strukturieren Sie dann Ihre Regel so, und gewähren bedingt Zugriff. Erstellen Sie in Realtime Database einen Datenpfad, der die Nutzer Ihrer App definiert und ihnen eine Rolle in einem untergeordneten Knoten zuweist.
Du kannst auch benutzerdefinierte Ansprüche in Authentication einrichten
und rufen diese Informationen dann vom
auth.token-Variable in einem beliebigen Firebase Security Rules.
Datendefinierte Attribute und Rollen
Diese Regeln funktionieren nur in Cloud Firestore und Realtime Database.
Cloud Firestore
Wenn Ihre Regeln einen Lesevorgang enthalten (wie bei den Regeln unten), wird Ihnen ein Lesevorgang in Cloud Firestore in Rechnung gestellt.
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
Richte zur Implementierung dieser Regeln benutzerdefinierte Ansprüche ein. in Firebase Authentication und nutzen Sie dann die Ansprüche in Ihren Regeln.
Cloud Firestore
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";
}
}
}
Realtime Database
{
"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"
}
}
}
}
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;
}
}
Mandantenattribute
Richten Sie in der Google Cloud Identity Platform (GCIP) die Mehrinstanzenfähigkeit ein, um diese Regeln zu implementieren
und nutzen ihn dann in Ihren Regeln. Die folgenden Beispiele erlauben Schreibvorgänge
von einem Nutzer in einem bestimmten Mandanten, 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;
}
}