Scanner de regras Firebase: encontre regras abertas no Firestore, Realtime Database e Storage

Como o scanner encontra regras Firebase abertas

Serviços Firebase expõem formatos de URL bem conhecidos e previsíveis. Um scanner sem credenciais pode sondar cada um e observar se as leituras anônimas têm sucesso. A verificação baas.firebase-rules do FixVibe roda em três sondagens independentes — uma por serviço Firebase:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database. O scanner sonda https://[project-id]-default-rtdb.firebaseio.com/.json. Se a raiz for legível anonimamente, a resposta é a árvore completa do banco como JSON. Um teste mais conservador consulta .json?shallow=true, que retorna apenas chaves de topo — um achado em qualquer caso.
• Cloud Storage. O scanner consulta https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o. Se a resposta listar nomes de arquivos sem autenticação, o bucket é listável anonimamente. Storage listável é um achado mesmo quando downloads individuais de arquivos são negados — atacantes enumeram o bucket para achar nomes de arquivos adivináveis.

Como o footgun de modo de teste realmente parece

A documentação de quickstart do Firebase inclui um dos blocos de regras mais copiados da internet:

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

O Firebase costumava adicionar uma expiração automática de 30 dias nessas regras. Isso mudou: hoje as regras persistem para sempre a menos que o desenvolvedor as substitua. Ferramentas de codificação com IA — treinadas em anos de documentação que inclui o bloco de modo de teste — frequentemente o emitem textualmente e dizem ao desenvolvedor "esta é sua regra de segurança". Não é.

Outras variantes que aparecem em produção mas são igualmente permissivas:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• Uma variante de timestamp futuro: uma regra que permite tudo até uma data distante no futuro. Nunca expira efetivamente (veja o bloco destacado acima).
• allow read: if true; allow write: if request.auth != null; — leituras públicas, qualquer usuário autenticado pode escrever.
• allow read, write: if request.auth != null; — qualquer usuário logado pode ler ou escrever qualquer documento, incluindo dados de outros usuários.

O que fazer quando o scanner encontra uma regra aberta

Regras abertas do Firebase são uma emergência em produção. A correção tem o mesmo formato em todos os três serviços: restrinja cada regra a request.auth.uid contra um campo de dono explícito. Cada serviço tem sua própria sintaxe de regras:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }. O binding de segmento de caminho {userId} se torna o único documento que o usuário pode tocar.

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

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }. Convenção: armazene arquivos sob users/[uid]/[filename] e deixe o caminho impor a propriedade.

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

Publique as regras via CLI do Firebase: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verifique que as novas regras estão em produção re-rodando a varredura do FixVibe — o achado baas.firebase-rules deve desaparecer.

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

Como isso se compara às ferramentas embutidas do Firebase

O console do Firebase mostra as regras atuais mas não as audita contra o comportamento em runtime. O simulador de regras do Firebase deixa você testar a lógica de regras contra requisições sintéticas — útil mas local. Nenhuma das duas ferramentas diz o que suas regras de produção realmente retornam a um atacante anônimo na internet pública. Um scanner externo como o FixVibe (ou Burp Suite com configuração manual) é a única coisa que sonda do mesmo ângulo que um atacante faria. O próprio App Check do Google mitiga abuso mas não substitui regras corretamente restritas.

Perguntas frequentes

Próximos passos

Rode uma varredura gratuita do FixVibe contra sua URL de produção — a verificação baas.firebase-rules está em todos os planos e sinaliza regras abertas no Firestore, Realtime Database e Cloud Storage. Para uma explicação mais profunda do padrão allow read, write: if true especificamente, veja Firebase allow read, write: if true explicado. Para a visão geral sobre Supabase, Firebase, Clerk e Auth0, leia Scanner de configurações incorretas de BaaS.