O Firebase vai estar de volta no Cloud Next de 9 a 11 de abril. Inscreva-se agora.

Esta página foi traduzida pela API Cloud Translation.

Evitar regras inseguras

Use este guia para entender as vulnerabilidades comuns nas configurações do Firebase Security Rules, 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 o Firebase Security Rules

Para ver as Rules atuais, use a CLI do Firebase ou o console do 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 Firebase Security Rules.

Para acessar as regras no console do Firebase, 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 CLI do Firebase, acesse o arquivo de regras mencionado no seu arquivo firebase.json.

Entenda as Firebase Security Rules

As 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 do Firebase, é possível negar o acesso a todos os usuários (modo bloqueado) ou conceder a todos (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

As Rules configuradas por padrão ou durante o desenvolvimento inicial do app precisam ser revisadas e atualizadas 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

Somente 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

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

Acesso para qualquer usuário autenticado

Às vezes, as 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

Somente 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 indevidamente

A Realtime Database Security Rules é aplicada em cascata, com regras em caminhos pai mais superficiais que substituem regras em 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 a cascata de 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 as Cloud Firestore Security Rules e como elas funcionam em Primeiras etapas com as Cloud Firestore Security Rules.

Testar o Cloud Firestore Security Rules

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

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