Grundlegende Sicherheitsregeln

Mit Firebase Security Rules können Sie den Zugriff auf Ihre gespeicherten Daten steuern. Dank der flexiblen Regelsyntax können Sie Regeln erstellen, die auf alles zutreffen, von allen Schreibvorgängen in der gesamten Datenbank bis hin zu Vorgängen für ein bestimmtes Dokument.

In diesem Leitfaden werden einige der grundlegenden Anwendungsfälle beschrieben, die Sie beim Einrichten Ihrer Anwendung und beim Schutz Ihrer Daten implementieren können. Bevor Sie jedoch mit dem Schreiben von Regeln beginnen, sollten Sie sich mit der Sprache, in der sie geschrieben sind, und ihrem Verhalten vertraut machen.

Wenn Sie auf Ihre Regeln zugreifen und sie aktualisieren möchten, folgen Sie der Anleitung unter Firebase Security Rules verwalten und bereitstellen.

Wenn Sie KI-Unterstützung benötigen, kopieren Sie den Prompt unten in Ihren KI-Coding-Agenten (z. B. Gemini in Android Studio, Antigravity, Claude Code, Codex und Cursor). Sie können den Prompt anpassen und mit Ihrem Agenten iterieren. Ausführliche Informationen zur Installation finden Sie unter Firebase-Agenten-Skills.

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's data.

Standardregeln: Sperrmodus

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

Regeln für Entwicklungsumgebungen

Während Sie an Ihrer Anwendung arbeiten, möchten Sie möglicherweise relativ offenen oder uneingeschränkten Zugriff auf Ihre Daten haben. Aktualisieren Sie aber unbedingt die Security Rules, bevor Sie Ihre Anwendung in der Produktion bereitstellen. Denken Sie auch daran, dass Ihre App öffentlich zugänglich ist, wenn Sie sie bereitstellen, auch wenn Sie sie noch nicht veröffentlicht haben.

Denken Sie daran, dass Firebase Clients direkten Zugriff auf Ihre Daten gewährt und Firebase Security Rules die einzige Schutzmaßnahme sind, 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 Zwischenserver angewiesen, 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, aber es kann 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 Anwendung bereitstellen, müssen Sie dafür sorgen, 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.

Es empfiehlt sich, Regeln zu schreiben, während Sie Ihre Daten strukturieren, da die Art und Weise, wie Sie Ihre Regeln einrichten, sich darauf auswirkt, wie Sie den Zugriff auf Daten in verschiedenen Pfaden einschränken.

Zugriff nur für Rechteinhaber

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

Wann diese Regel funktioniert: Diese Regel funktioniert gut, wenn Daten nach Nutzer isoliert sind, d. h. wenn der einzige Nutzer, der auf die Daten zugreifen muss, derselbe Nutzer ist, der die Daten erstellt hat.

Wann diese Regel nicht funktioniert: Dieser Regelsatz funktioniert nicht, wenn mehrere Nutzer dieselben Daten schreiben oder lesen müssen. Nutzer überschreiben dann Daten oder können nicht auf Daten zugreifen, die sie erstellt haben.

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 Eigentümer dieser Daten ist.

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

Diese Regel ermöglicht es jedem, ein Dataset zu lesen, beschränkt jedoch die Möglichkeit, Daten in einem bestimmten Pfad zu erstellen oder zu ändern, auf den authentifizierten Rechteinhaber.

Wann diese Regel funktioniert: Diese Regel eignet sich gut für Apps, die öffentlich lesbare Elemente erfordern, aber den Bearbeitungszugriff auf die Inhaber dieser Elemente beschränken müssen. Beispiele sind Chat-Apps oder Blogs.

Wann diese Regel nicht funktioniert: Wie die Regel „Nur Rechteinhaber“ funktioniert auch diese Regel 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 allen Nutzern (oder allen authentifizierten Nutzern) Lesezugriff gewährt und bestätigt, dass der Nutzer, der Daten schreibt, der Inhaber 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;
    }
  }
}

Attribut- und rollenbasierter Zugriff

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

Wann diese Regel funktioniert: 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“ (nur eigene Inhalte lesen), der Gruppe „Lehrkräfte“ (Inhalte im eigenen Fach lesen und schreiben) und der Gruppe „Schulleitung“ (alle Inhalte lesen) unterschiedliche Zugriffsebenen zuweisen.

Wann diese Regel nicht funktioniert: 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 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 Nutzer ein, das Sie lesen können. 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 Anforderungen in Authentication einrichten und diese Informationen dann aus der Variablen auth.token in einem beliebigen Firebase Security Rules abrufen.

Datendefinierte Attribute und Rollen

Diese Regeln funktionieren nur in Cloud Firestore und Realtime Database.

Cloud Firestore

Denken Sie daran, dass Ihnen jedes Mal, wenn Ihre Regeln einen Lesevorgang enthalten, wie die Regeln unten, 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
      }
    }
  }
}

Benutzerdefinierte Anspruchsattribute und ‑rollen

Wenn Sie diese Regeln implementieren möchten, richten Sie in Firebase Authentication benutzerdefinierte Anforderungen ein und verwenden Sie die Anforderungen 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;
  }
}

Mandantenattribute

Wenn Sie diese Regeln implementieren möchten, richten Sie die Mehrmandantenfähigkeit in der 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;
  }
}