// 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 usuário logado, o que é melhor mas ainda está errado: qualquer usuário do seu app pode ler os dados de qualquer outro usuário. Regras de produção devem restringir ao usuário ou org específico via request.auth.uid == resource.data.owner_uid ou similar.

Q: E se meu 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 do seu banco. 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 você cria um novo banco, a regra que ferramentas de codificação com IA regeneram da documentação e a regra que abre todo seu banco de dados Firestore para qualquer um na internet. Este artigo explica a sintaxe precisamente, mostra o que um atacante vê quando essa regra está ativa e dá quatro substituições progressivamente mais estritas que servem para diferentes casos de uso.

A sintaxe, linha por 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;
    }
  }
}

Decodificado:

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 o banco especial (default) (a maioria dos projetos tem apenas um).
match /{document=**} é um wildcard recursivo. O ** corresponde a qualquer caminho de qualquer profundidade. Combinado com {document}, isso captura cada documento em cada coleção — uma única cláusula match governando todo o banco.
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.

Por que o Firebase entrega isso como padrão

O Firebase quer que você esteja codando nos primeiros 30 segundos após criar um projeto. A alternativa — fazer você escrever uma regra correta antes que qualquer leitura ou escrita funcione — bloquearia o onboarding. Então o console oferece duas opções quando você cria um banco: Modo produção (negar tudo, você escreve as regras) ou Modo de teste (permitir tudo por 30 dias). A maioria dos desenvolvedores 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 você 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 essa regra não é segura para produção.

O que um atacante vê

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

Uma única requisição curl não autenticada 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, uma segunda requisição retorna documentos. Não há rate limit nesse caminho porque regras if true aceitam tráfego anônimo. Vimos bancos Firebase com milhões de documentos enumerados em menos de uma hora.

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

Quatro substituições seguras para produção

Escolha a substituição que combina com o modelo de dados do seu app. Todas as quatro assumem que você tem autenticação de usuário (Firebase Auth ou qualquer provedor que emita um token de ID Firebase):

Opção 1: documentos de propriedade do usuário

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 usuário), 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 usuário. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Requer definir o custom claim durante o cadastro 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 busque if true. Se você encontrar em qualquer lugar fora de um comentário, você tem um achado de regra aberta. O simulador de regras na mesma UI deixa você reproduzir a requisição do atacante localmente — cole um GET /users/somebody anônimo e confirme que o simulador retorna Allowed.

Confirmação externa: rode uma varredura do FixVibe contra sua URL de produção. A verificação baas.firebase-rules sonda 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 usuário logado, o que é melhor mas ainda está errado: qualquer usuário do seu app pode ler os dados de qualquer outro usuário. Regras de produção devem restringir ao usuário ou org específico via request.auth.uid == resource.data.owner_uid ou similar.

O Firebase já 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 você criou seu projeto antes de 2023 e suas regras parecem ok, verifique duas vezes: o timer pode já tê-las virado para if false, o que bloqueia seu próprio app.

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

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

E se meu 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 do seu banco. Use uma cláusula match separada por coleção e nunca use o wildcard recursivo {document=**} em regras de escrita.

Próximos passos

Rode uma varredura do FixVibe contra 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 detecçõ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.