// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true explicado: o que faz e como corrigir

Q: Qual é a diferença entre if true e if request.auth != null ?

if true permite acesso anónimo — qualquer um na internet. if request.auth != null requer qualquer utilizador autenticado, o que é melhor mas ainda está errado: qualquer utilizador da sua app pode ler os dados de qualquer outro utilizador. Regras de produção devem restringir ao utilizador ou org específico via request.auth.uid == resource.data.owner_uid ou similar.

Q: E se a minha app é genuinamente de leitura pública (blog, catálogo de produtos)?

Então escreva explicitamente allow read: if true; allow write: if false; apenas na coleção pública — não em cada coleção da sua base de dados. Use uma cláusula match separada por coleção e nunca use o wildcard recursivo '{'document=**'}' em regras de escrita.

<code>allow read, write: if true;</code> é a configuração incorreta de Firebase mais comum em produção. É o padrão de modo de teste que o console do Firebase sugere quando cria uma nova base de dados, a regra que ferramentas de codificação com IA regeneram da documentação e a regra que abre toda a sua base de dados Firestore a qualquer um na internet. Este artigo explica a sintaxe precisamente, mostra o que um atacante vê quando esta regra está ativa e dá quatro substituições progressivamente mais estritas que servem para diferentes casos de uso.

A sintaxe, linha a linha

Um documento completo de regras do Firestore em modo de teste tem seis linhas:

firebase

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

Descodificado:

rules_version = '2'; seleciona o motor de regras v2 (atual). Regras v1 mais antigas estão obsoletas.
service cloud.firestore restringe o bloco ao Firestore. Realtime Database usa uma sintaxe baseada em JSON diferente; Cloud Storage usa service firebase.storage.
match /databases/{database}/documents vincula a base de dados especial (default) (a maioria dos projetos tem apenas uma).
match /{document=**} é um wildcard recursivo. O ** corresponde a qualquer caminho de qualquer profundidade. Combinado com {document}, isto captura cada documento em cada coleção — uma única cláusula match que governa toda a base de dados.
allow read, write: if true; é o corpo da regra. Tanto read quanto write são permitidos; a condição if true é, bem, sempre verdadeira. read cobre operações get e list; write cobre create, update e delete.

Efeito líquido: qualquer cliente com o ID do projeto Firebase e o SDK certo pode ler ou escrever qualquer documento em qualquer coleção. Autenticação não é requerida. Rate limits não são aplicados.

Porque é que o Firebase entrega isto como padrão

O Firebase quer que esteja a codificar nos primeiros 30 segundos após criar um projeto. A alternativa — forçá-lo a escrever uma regra correta antes que qualquer leitura ou escrita funcione — bloquearia o onboarding. Então o console oferece duas opções quando cria uma base de dados: Modo produção (negar tudo, escreve as regras) ou Modo de teste (permitir tudo por 30 dias). A maioria dos programadores clica em modo de teste e depois esquece de revisitar. Projetos antigos tinham o timer de 30 dias; projetos atuais têm uma regra if true indefinida sem expiração automática.

O problema estrutural: ferramentas de codificação com IA treinam em documentação, tutoriais e respostas do Stack Overflow que mostram regras de modo de teste. Quando pergunta ao Cursor ou Claude Code "como configuro o Firebase", a resposta frequentemente inclui o bloco exato allow read, write: if true como se fosse a regra de produção. A IA não sabe — e não é induzida a saber — que esta regra não é segura para produção.

O que um atacante vê

Concretamente, um atacante que sabe o seu ID de projeto Firebase (extraível do bundle de qualquer app publicada em 30 segundos) e executa o seguinte pode listar cada documento em cada coleção:

Um único pedido curl não autenticado basta para enumerar cada coleção. Veja o bloco destacado abaixo.

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

A resposta é a lista completa de coleções de topo. Para cada coleção, um segundo pedido devolve documentos. Não há rate limit neste caminho porque regras if true aceitam tráfego anónimo. Vimos bases de dados Firebase com milhões de documentos enumeradas em menos de uma hora.

No caminho de escrita: um único POST com {fields} cria um novo documento. Atacantes podem poluir as suas coleções com lixo, desfigurar páginas voltadas ao utilizador que leem do Firestore ou usar a sua base de dados como um message broker gratuito — a sua fatura de utilização explode, investiga, a fatura explica o problema.

Quatro substituições seguras para produção

Escolha a substituição que combina com o modelo de dados da sua app. Todas as quatro assumem que tem autenticação de utilizador (Firebase Auth ou qualquer fornecedor que emita um token de ID Firebase):

Opção 1: documentos de propriedade do utilizador

Padrão SaaS mais comum. Documentos vivem sob /users/{userId}/... e apenas o dono pode tocá-los. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Opção 2: campo de dono em cada documento

Quando documentos vivem em coleções planas (não aninhados sob ID de utilizador), armazene um campo owner_uid e verifique. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Opção 3: isolamento multi-tenant por org

Para SaaS B2B com dados restritos por org. Armazene um campo org_id em cada documento e verifique contra o custom claim do utilizador. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Requer definir o custom claim durante o registo via SDK Admin do Firebase.

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

Opção 4: conteúdo público apenas de leitura

Para conteúdo de marketing, perfis públicos, catálogos de produtos — qualquer coisa que é genuinamente de leitura pública mas escrita apenas por admin. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. O custom claim admin é definido apenas em contas de admin.

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Consulta de auditoria rápida

Antes de corrigir, verifique se if true está realmente ativo. Abra Console Firebase → Firestore → Rules e procure if true. Se encontrar em qualquer lugar fora de um comentário, tem um achado de regra aberta. O simulador de regras na mesma UI deixa reproduzir o pedido do atacante localmente — cole um GET /users/somebody anónimo e confirme que o simulador devolve Allowed.

Confirmação externa: execute um varrimento do FixVibe contra a sua URL de produção. A verificação baas.firebase-rules sonda as suas regras de Firestore, Realtime Database e Storage e reporta o mesmo achado que um atacante descobriria — independente do que o console do Firebase mostra.

Perguntas frequentes

Qual é a diferença entre <code>if true</code> e <code>if request.auth != null</code>?

if true permite acesso anónimo — qualquer um na internet. if request.auth != null requer qualquer utilizador autenticado, o que é melhor mas ainda está errado: qualquer utilizador da sua app pode ler os dados de qualquer outro utilizador. Regras de produção devem restringir ao utilizador ou org específico via request.auth.uid == resource.data.owner_uid ou similar.

O Firebase alguma vez expira regras <code>if true</code> automaticamente?

Projetos antigos (pré-2023) tinham um timer de 30 dias que convertia regras if true em if false. Projetos atuais não — a regra persiste indefinidamente até ser substituída manualmente. Se criou o seu projeto antes de 2023 e as suas regras parecem ok, verifique duas vezes: o timer pode já tê-las virado para if false, o que bloqueia a sua própria app.

Posso usar uma verificação de timestamp futuro como rede de segurança?

Não — uma condição de timestamp não é um controlo de segurança. Ela expira a regra aberta numa data futura, o que significa que até essa data atacantes têm acesso total. E vai esquecer a data. Substitua if true por uma regra restrita por autenticação, não uma limitada por tempo.

E se a minha app é genuinamente de leitura pública (blog, catálogo de produtos)?

Então escreva explicitamente allow read: if true; allow write: if false; apenas na coleção pública — não em cada coleção da sua base de dados. Use uma cláusula match separada por coleção e nunca use o wildcard recursivo {document=**} em regras de escrita.

Próximos passos

Execute um varrimento do FixVibe contra a sua URL de produção — a verificação baas.firebase-rules confirma se if true é atualmente explorável pela internet pública. Para os mecanismos do scanner e as deteções paralelas para Realtime Database e Storage, veja Scanner de regras Firebase. Para a classe equivalente de configuração incorreta no Supabase, leia Scanner de RLS Supabase.