// Segurança por ferramenta
Segurança para apps feitos no Firebase Studio
Resposta rápida
No Firebase, o furo quase sempre é a Security Rule permissiva: Firestore ou Storage configurado pra aceitar leitura e escrita de qualquer um (o famoso allow read, write: if true). É a configuração insegura por padrão que mais vaza. Em 2025, um bucket de Storage aberto sem autenticação expôs dezenas de milhares de imagens, incluindo fotos de documento, e depois mais de um milhão de mensagens privadas.
Se você subiu no Firebase Studio e tem dado de usuário ou upload, a primeira revisão é a regra: quem pode ler e escrever cada coleção do Firestore e cada caminho do Storage.
O que costuma quebrar no Firebase
O Firebase é poderoso, mas a segurança vive inteira nas Security Rules, e é fácil deixar em modo permissivo pra destravar o desenvolvimento e esquecer de fechar antes de publicar.
| Furo | Por que acontece | Impacto |
|---|---|---|
| Rule allow if true | Regra aberta deixada do desenvolvimento | Leitura/escrita pública do banco |
| Storage bucket sem auth | Caminho de upload sem regra de acesso | Vazamento de arquivo/documento |
| Regra sem checar dono | Acesso por coleção, não por usuário | Usuário lê dado de outro |
| API key exposta | Config do Firebase no client (esperado) mas sem regra | Sem regra, a key vira acesso |
Como a RET revisa um app feito no Firebase Studio
A RET lê as Security Rules do Firestore e do Storage coleção por coleção, caminho por caminho: onde está if true, onde falta checar o dono (request.auth.uid), qual bucket abre sem autenticação. E testa na prática o que uma requisição não autenticada consegue ler ou gravar. Achado com reprodução e prioridade.
Pra rodar sozinho, o Promptbook tem prompt específico pra revisar Security Rules. Sinal sério vai pro Risk Review.
- Leitura das Security Rules do Firestore e do Storage.
- Teste de requisição não autenticada (o que lê/grava?).
- Checagem de checagem de dono (request.auth.uid) por coleção.
Você já pode estar exposto se
Sinais que pedem revisão num app Firebase:
- Suas Security Rules ainda têm algum allow read, write: if true.
- Você tem upload e nunca conferiu a regra do Storage.
- Suas regras liberam por coleção sem checar o dono do documento.
- Você não sabe o que uma requisição sem login consegue ler no seu Firestore.
Perguntas frequentes
A API key do Firebase no client é um problema?
A config do Firebase (incluindo a apiKey) é feita pra ficar no client, isso é esperado. O problema não é a key, são as Security Rules: se elas estão permissivas, a key vira acesso ao banco. A proteção real está na regra, não em esconder a config.
O que é a regra if true?
É a Security Rule que libera leitura e escrita pra qualquer um (allow read, write: if true), normalmente deixada durante o desenvolvimento pra não travar. Se ela vai pra produção, o banco inteiro fica público. É o furo número um em app Firebase.
Como fecho isso direito?
Com regra que checa autenticação e dono: cada documento só é lido/escrito por quem é dono (request.auth.uid). A revisão da RET mapeia coleção por coleção o que está aberto e o que falta checar.
Quem faz a revisão na RET?
Gabriel Lima Ferreira, founder e lead pentester, com autorização e escopo fechado.