Firebase Security Rules: pare de deixar seu banco de dados aberto
Apps web com Firebase leem e gravam no Firestore, Realtime Database e Cloud Storage direto do navegador, usando um objeto de configuração que qualquer um pode ver. As Security Rules são a única coisa que decide se uma requisição é permitida. Regras deixadas em modo de teste, ou afrouxadas para permitir tudo, expõem o seu banco de dados inteiro à internet.
O que é
Security Rules são uma pequena linguagem de políticas avaliada nos servidores do Google a cada leitura e escrita. Cada bloco match mira um caminho — uma coleção, um documento, uma pasta do storage — e as instruções allow dizem quais operações são permitidas e sob quais condições, usando request.auth (quem está pedindo) e request.resource.data (o que estão tentando gravar).
A config web do Firebase, incluindo a apiKey, só identifica o seu projeto; ela não é um segredo e não concede acesso por si só. É por isso que as regras importam tanto: qualquer visitante pode inicializar o SDK do Firebase com a sua config e consultar o seu banco de dados direto do console do próprio navegador.
Por que importa
O modo de teste do Firestore permite todas as leituras e escritas até uma data de expiração. Quando o prazo vence e o app quebra, uma "correção" comum é allow read, write: if true — o que deixa todos os documentos legíveis e graváveis por qualquer pessoa. Bancos Firebase expostos são uma fonte recorrente de grandes vazamentos de dados, e encontrá-los e despejá-los é trivial.
Regras que só verificam request.auth != null não são muito melhores: qualquer um pode criar uma conta, muitas vezes anônima, e então ler os dados de todos os usuários. Sem validar as escritas, os usuários também podem editar campos que nunca deveriam controlar — por exemplo, definir role: "admin" no próprio perfil.
Como corrigir
Negue por padrão e conceda acesso coleção por coleção. Aqui cada usuário só pode ler e gravar o próprio documento em users, e nada mais fica acessível.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}
// Every other path is denied by default.
}
}Restrinja quais campos um usuário pode alterar para que ele não consiga se promover nem mexer em dados gerenciados pelo servidor. affectedKeys().hasOnly() rejeita qualquer atualização que toque em outros campos.
match /users/{userId} {
allow update: if request.auth.uid == userId
&& request.resource.data.diff(resource.data)
.affectedKeys().hasOnly(["displayName", "photoURL"]);
}Procure nas suas regras por match /{document=**} combinado com um allow amplo, por if true e por timestamps de expiração do modo de teste. Lembre-se de que o Cloud Storage e o Realtime Database têm arquivos de regras separados — proteja-os também.
Use o Rules Playground no console do Firebase ou o Emulator Suite com @firebase/rules-unit-testing para executar leituras como usuário não autenticado e como outro usuário logado. Uma verificação externa rápida é uma requisição REST sem autenticação — se ela retornar documentos, a coleção é pública.
curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/users"FAQ
A apiKey do Firebase é um segredo?
Não. A apiKey na config web do Firebase identifica o seu projeto e foi feita para ir para o navegador. Proteja seus dados com Security Rules e restrinja a chave no Google Cloud às APIs que o seu app realmente usa, para que ela não possa ser reaproveitada em outros serviços pagos do Google.
request.auth != null é suficiente?
Raramente. Isso só prova que quem faz a requisição está logado — não que os dados pertencem a ele. Compare request.auth.uid com o dono do documento, ou verifique um papel que os usuários não consigam definir por conta própria.
O AppSafe verifica minhas regras do Firebase?
O AppSafe não consulta o seu projeto Firebase, então não consegue avaliar suas regras — use o Rules Playground ou a verificação com curl acima. Mas ele sinaliza API keys do Google (o formato AIza…) encontradas no seu JavaScript, porque o mesmo formato é usado em serviços pagos como Maps ou Gemini. Numa config web do Firebase isso é o esperado; só garanta que a chave esteja restrita.
Seu app está afetado?
O AppSafe verifica isso e dezenas de outros problemas em um único escaneamento grátis.
Escanear meu app grátisGuias relacionados
Row Level Security (RLS) no Supabase: proteja suas tabelas
Sua anon key é pública. O RLS é a única coisa entre ela e os seus dados.
API keys expostas no JavaScript do cliente
Tudo no seu bundle é público. Trate assim.
Backups de banco de dados expostos: o que acontece quando /backup.sql está acessível
Um dump .sql acessível é a entrega completa de todo o seu banco de dados.