O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Evitar regras inseguras

Use este guia para entender as vulnerabilidades comuns nas Firebase Security Rules configurações, revisar e proteger melhor suas próprias regras, e testar as alterações antes de implantá-las.

Se você receber um alerta de que seus dados não estão protegidos de modo adequado, analise os erros comuns e atualize as regras que estiverem vulneráveis.

Acessar seu Firebase Security Rules

Para ver os Security Rules atuais, use a CLI Firebase ou o console Firebase. Lembre de editar as regras usando o mesmo método de maneira consistente para evitar substituir as atualizações por engano. Caso você não tenha certeza de que as regras definidas localmente correspondem às atualizações mais recentes, saiba que o console do Firebase sempre mostra a versão implantada mais recentemente das regras de segurança do Firebase.Firebase Security Rules

Para acessar as regras no Firebase console, selecione o projeto e navegue até Realtime Database, Cloud Firestore ou Storage. Clique em Regras quando estiver no banco de dados ou no bucket correto.

Para acessar suas regras pela Firebase CLI, acesse o arquivo de regras mencionado no seu arquivo firebase.json.

Entender Firebase Security Rules

Firebase Security Rules protegem seus dados contra usuários mal-intencionados. Ao criar uma instância de banco de dados ou um bucket Cloud Storage no console Firebase, é possível optar por negar o acesso a todos os usuários (Modo bloqueado) ou conceder acesso a todos usuários (Modo de teste). Apesar de ser recomendável ter uma configuração mais ampla durante o desenvolvimento, não se esqueça de configurar corretamente as regras e proteger os dados antes de implantar o app.

Quando estiver desenvolvendo o aplicativo e testando diferentes configurações para as regras, use um dos emuladores locais do Firebase para executar o aplicativo em um ambiente de desenvolvimento local.

Cenários comuns com regras não seguras

O Security Rules configurado por padrão ou durante o desenvolvimento inicial do app precisa ser revisado e atualizado antes da implantação. Proteja corretamente os dados dos usuários, evitando as armadilhas comuns a seguir.

Acesso aberto

Ao configurar o projeto do Firestore, pode ser que você tenha definido as regras para permitir acesso aberto durante o desenvolvimento. Talvez você acredite que é a única pessoa que usa o aplicativo. No entanto, se você o implantou, ele está disponível na Internet. Se você não tiver autenticado usuários e configurado regras de segurança, qualquer pessoa que adivinhar o código do projeto pode roubar, modificar ou excluir os dados.

Não recomendável: acesso de leitura e gravação para todos os usuários.

Cloud Firestore

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

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

Realtime Database

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

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

Cloud Storage

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded using App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

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

Solução: regras que restringem o acesso de leitura e gravação.

Desenvolva regras que façam sentido para sua hierarquia de dados. Uma das soluções comuns para essa falha é a segurança baseada no usuário com o Firebase Authentication. Saiba mais sobre como autenticar usuários usando as regras.

Cloud Firestore

Apenas o proprietário do conteúdo

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // 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;

    }
  }
}

Acesso público e privado misto

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

Apenas o proprietário do conteúdo

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

Acesso público e privado misto

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

Apenas o proprietário do conteúdo

// 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.uid == userId;
    }
  }
}

Acesso público e privado misto

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

Acesso para qualquer usuário autenticado

Às vezes, as Security Rules verificam se um usuário está conectado, mas não restringem o acesso com base nessa autenticação. Se uma de suas regras incluir auth != null, confirme se você quer que qualquer usuário que fez login tenha acesso aos dados.

Não recomendável: qualquer usuário conectado tem acesso de leitura e gravação a todo o banco de dados.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Solução: restrinja o acesso usando as condições de segurança.

Se você fizer a verificação de autenticação, talvez também seja interessante usar uma dessas propriedades para restringir ainda mais o acesso de determinados usuários a conjuntos de dados específicos. Saiba mais sobre as diferentes propriedades de autenticação.

Cloud Firestore

Acesso com base em papéis

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    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"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

Acesso com base em atributos

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "administrator" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}

Acesso público e privado misto

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 write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}

Realtime Database

Apenas o proprietário do conteúdo

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid"
      }
    }
  }
}

Acesso definido pelo caminho

{
  "rules": {
    "some_path/$uid": {
      ".write": "auth.uid === $uid",
      // Create a "public" subpath in your dataset
      "public": {
        ".read": true
        // or ".read": "auth.uid !== null"
      },
      // Create a "private" subpath in your dataset
      "private": {
        ".read": "auth.uid === $uid"
      }
    }
  }
}

Acesso público e privado misto

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

Acesso com base em grupos

// Allow reads if the group ID in your token matches the file metadata `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;
}

Somente o proprietário do conteúdo

// 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.uid == userId;
    }
  }
}

Acesso público e privado misto

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

(Realtime Database) Regras herdadas incorretamente

Realtime Database Security Rules são aplicadas em cascata, e as regras nos caminhos pai mais superficiais substituem regras nos nós filhos mais profundos. Ao gravar uma regra em um nó filho, lembre que ela só pode conceder privilégios adicionais. Não é possível refinar ou revogar o acesso aos dados em um caminho mais profundo do seu banco de dados.

Não recomendado: refinar regras em caminhos filhos.

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

Solução: grave regras em caminhos pai que sejam amplos e conceda privilégios mais específicos a caminhos filhos. Se suas necessidades de acesso a dados exigirem mais granularidade, crie regras detalhadas. Saiba mais sobre Realtime Database Security Rules em sintaxe principal de Realtime Database Security Rules.

Acesso fechado

Ao desenvolver seu aplicativo, outra abordagem comum é manter seus dados bloqueados. Normalmente, isso significa bloquear o acesso de leitura e gravação a todos os usuários da seguinte maneira:

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

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

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

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

Os SDKs Admin do Firebase e o Cloud Functions ainda podem acessar seu banco de dados. Use essas regras quando você quiser usar Cloud Firestore ou Realtime Database como um back-end somente para servidores com o SDK Admin do Firebase. Embora seja seguro, é necessário testar se os clientes do seu aplicativo podem recuperar dados adequadamente.

Saiba mais sobre Cloud Firestore Security Rules e como elas funcionam em Primeiras etapas com Cloud Firestore Security Rules.

Testar o seu Cloud Firestore Security Rules

Para verificar o comportamento do seu aplicativo e conferir suas Cloud Firestore Security Rules configurações, use o emulador do Firebase. Utilize o Cloud Firestore emulador para executar e automatizar testes de unidade em um ambiente local antes de implantar as alterações.

Para validar rapidamente Firebase Security Rules no console Firebase, use o simulador de regras do Firebase.

Evitar regras inseguras Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Acessar seu Firebase Security Rules

Entender Firebase Security Rules

Cenários comuns com regras não seguras

Acesso aberto

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Apenas o proprietário do conteúdo

Acesso público e privado misto

Realtime Database

Apenas o proprietário do conteúdo

Acesso público e privado misto

Cloud Storage

Apenas o proprietário do conteúdo

Acesso público e privado misto

Acesso para qualquer usuário autenticado

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Acesso com base em papéis

Acesso com base em atributos

Acesso público e privado misto

Realtime Database

Apenas o proprietário do conteúdo

Acesso definido pelo caminho

Acesso público e privado misto

Cloud Storage

Acesso com base em grupos

Somente o proprietário do conteúdo

Acesso público e privado misto

(Realtime Database) Regras herdadas incorretamente

Acesso fechado

Cloud Firestore

Realtime Database

Cloud Storage

Testar o seu Cloud Firestore Security Rules

Evitar regras inseguras