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 corre 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 da base de dados como JSON. Um teste mais conservador consulta .json?shallow=true, que devolve 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 ficheiros sem autenticação, o bucket é listável anonimamente. Storage listável é um achado mesmo quando descargas individuais de ficheiros são negadas — atacantes enumeram o bucket para encontrar nomes de ficheiros 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 nestas regras. Isso mudou: hoje as regras persistem para sempre a menos que o programador as substitua. Ferramentas de codificação com IA — treinadas em anos de documentação que inclui o bloco de modo de teste — frequentemente emitem-no textualmente e dizem ao programador "esta é a tua 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 utilizador autenticado pode escrever.
• allow read, write: if request.auth != null; — qualquer utilizador autenticado pode ler ou escrever qualquer documento, incluindo dados de outros utilizadores.

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 nos três serviços: restrinja cada regra a request.auth.uid contra um campo de dono explícito. Cada serviço tem a 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} torna-se o único documento que o utilizador 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 ficheiros 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-executando o varrimento do FixVibe — o achado baas.firebase-rules deve desaparecer.

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

Como isto 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 testar a lógica de regras contra pedidos sintéticos — útil mas local. Nenhuma das duas ferramentas diz o que as suas regras de produção realmente devolvem 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 da Google mitiga abuso mas não substitui regras corretamente restritas.

Perguntas frequentes

Próximos passos

Execute um varrimento gratuito do FixVibe contra a 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.