Regras básicas de segurança

As regras de segurança do Firebase permitem que você controle o acesso aos seus dados armazenados. A sintaxe de regras flexível significa que você pode criar regras que correspondam a qualquer coisa, desde todas as gravações no banco de dados inteiro até operações em um documento específico.

Este guia descreve alguns dos casos de uso mais básicos que você pode querer implementar ao configurar seu aplicativo e proteger seus dados. No entanto, antes de começar a escrever regras, você pode querer aprender mais sobre a linguagem em que elas são escritas e seu comportamento .

Para acessar e atualizar suas regras, siga as etapas descritas em Gerenciar e implantar regras de segurança do Firebase .

Regras padrão: modo bloqueado

Ao criar um banco de dados ou instância de armazenamento no console do Firebase, você escolhe se as regras de segurança do Firebase restringem o acesso aos seus dados ( modo bloqueado ) ou permitem o acesso de qualquer pessoa ( modo de teste ). No Cloud Firestore e no Realtime Database, as regras padrão para o modo bloqueado negam acesso a todos os usuários. No Cloud Storage, apenas usuários autenticados podem acessar os buckets de armazenamento.

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

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

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

Regras do ambiente de desenvolvimento

Enquanto você trabalha em seu aplicativo, talvez você queira acesso relativamente aberto ou irrestrito aos seus dados. Apenas certifique-se de atualizar suas regras antes de implantar seu aplicativo em produção. Lembre-se também de que, se você implantar seu aplicativo, ele ficará acessível publicamente, mesmo que você não o tenha iniciado .

Lembre-se de que o Firebase permite que os clientes tenham acesso direto aos seus dados, e as regras de segurança do Firebase são a única proteção que bloqueia o acesso de usuários mal-intencionados. Definir regras separadamente da lógica do produto tem uma série de vantagens: os clientes não são responsáveis ​​por impor a segurança, implementações com erros não comprometerão seus dados e, o mais importante, você não depende de um servidor intermediário para proteger os dados do mundo.

Todos os usuários autenticados

Embora não seja recomendável deixar seus dados acessíveis a qualquer usuário conectado, pode ser útil definir o acesso a qualquer usuário autenticado enquanto você desenvolve seu aplicativo.

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

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

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

Regras prontas para produção

Ao se preparar para implantar seu aplicativo, certifique-se de que seus dados estejam protegidos e que o acesso seja concedido adequadamente aos seus usuários. Aproveite a autenticação para configurar o acesso baseado em usuário e leia diretamente do seu banco de dados para configurar o acesso baseado em dados.

Considere escrever regras à medida que você estrutura seus dados, pois a maneira como você configura suas regras afeta a forma como você restringe o acesso aos dados em diferentes caminhos.

Acesso exclusivo do proprietário do conteúdo

Estas regras restringem o acesso apenas ao proprietário autenticado do conteúdo. Os dados só podem ser lidos e gravados por um usuário, e o caminho dos dados contém o ID do usuário.

Quando esta regra funciona: Esta regra funciona bem se os dados estiverem isolados por usuário — se o único usuário que precisa acessar os dados for o mesmo usuário que os criou.

Quando esta regra não funciona: Este conjunto de regras não funciona quando vários usuários precisam escrever ou ler os mesmos dados — os usuários substituirão os dados ou não conseguirão acessar os dados que criaram.

Para configurar esta regra: Crie uma regra que confirme que o usuário que solicita acesso para leitura ou gravação de dados é o proprietário desses dados.

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

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

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

Acesso misto público e privado

Esta regra permite que qualquer pessoa leia um conjunto de dados, mas restringe a capacidade de criar ou modificar dados em um determinado caminho apenas ao proprietário do conteúdo autenticado.

Quando esta regra funciona: Esta regra funciona bem para aplicativos que exigem elementos legíveis publicamente, mas precisam restringir o acesso de edição aos proprietários desses elementos. Por exemplo, um aplicativo de bate-papo ou blog.

Quando esta regra não funciona: Tal como a regra apenas para o proprietário do conteúdo, este conjunto de regras não funciona quando vários utilizadores precisam de editar os mesmos dados. Os usuários acabarão por sobrescrever os dados uns dos outros.

Para configurar esta regra: Crie uma regra que permita acesso de leitura para todos os usuários (ou todos os usuários autenticados) e confirme que o usuário que grava os dados é o proprietário.

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

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

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

Acesso baseado em atributos e em funções

Para que essas regras funcionem, você deve definir e atribuir atributos aos usuários em seus dados. As regras de segurança do Firebase verificam a solicitação em relação aos dados do seu banco de dados ou aos metadados do arquivo para confirmar ou negar o acesso.

Quando esta regra funciona: se você estiver atribuindo uma função aos usuários, esta regra facilita a limitação do acesso com base em funções ou grupos específicos de usuários. Por exemplo, se você estivesse armazenando notas, poderia atribuir diferentes níveis de acesso ao grupo "alunos" (ler apenas o conteúdo), ao grupo "professores" (ler e escrever em suas disciplinas) e ao grupo "diretores" (ler Todo o conteúdo).

Quando esta regra não funciona: no Realtime Database e no Cloud Storage, suas regras não podem aproveitar o método get() que as regras do Cloud Firestore podem incorporar. Conseqüentemente, você precisa estruturar seu banco de dados ou metadados de arquivo para refletir os atributos que está usando em suas regras.

Para configurar esta regra: No Cloud Firestore, inclua um campo nos documentos dos usuários que você possa ler e, em seguida, estruture sua regra para ler esse campo e conceder acesso condicionalmente. No Realtime Database, crie um caminho de dados que defina os usuários do seu aplicativo e conceda a eles uma função em um nó filho.

Você também pode configurar declarações personalizadas no Authentication e recuperar essas informações da variável auth.token em qualquer regra de segurança do Firebase.

Atributos e funções definidos por dados

Essas regras funcionam apenas no Cloud Firestore e no Realtime Database.

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

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

Atributos e funções de declaração personalizada

Para implementar essas regras, configure declarações personalizadas no Firebase Authentication e aproveite as declarações nas suas regras.

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

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

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

Atributos de locação

Para implementar essas regras, configure a multilocação no Google Cloud Identity Platform (GCIP) e aproveite o locatário nas suas regras. Os exemplos a seguir permitem gravações de um usuário em um locatário específico, por exemplo tenant2-m6tyz

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

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

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