Por que as regras permissivas são perigosas?

Regras mal configuradas são uma das vulnerabilidades mais comuns e perigosas em aplicações Firebase. Elas podem permitir que atacantes:

• Leiam Dados de Outros Usuários: Uma regra como `allow read: if request.auth != null;` em uma coleção `users` permite que qualquer usuário logado leia os dados de todos os outros usuários.
• Modifiquem ou Excluam Dados Alheios: Uma regra de escrita permissiva pode permitir que um usuário altere o perfil ou os dados de outro, causando caos e corrupção de dados.
• Criem Dados Indesejados: Permitir a escrita anônima (`allow write: if true;`) abre seu banco de dados para spam e abuso, o que pode levar a custos elevados e um banco de dados poluído.

Como o Oraculum funciona? Teste de Intrusão Real.

O Oraculum não se limita a suposições. Ele realiza um teste de intrusão (penetration test) ativo e realista, agindo como um hacker faria:

1. Uso da Chave de API: Após encontrar a chave de API e o ID do projeto no seu frontend, o Oraculum os utiliza para interagir com a API REST do Firestore.
2. Teste de Leitura Anônima: Ele tenta ler dados de coleções com nomes comuns (como `users`, `test`, `admin`, `config`) sem fornecer nenhuma autenticação. Se obtiver sucesso, relata uma vulnerabilidade crítica.
3. Teste de Escrita Anônima: O Oraculum tenta criar um novo documento em uma coleção com um nome de teste aleatório. Se a operação for bem-sucedida, isso prova que a escrita anônima é permitida, uma falha gravíssima.

Se o servidor do Firestore retornar um erro de "Permissão Negada" (status 403), o Oraculum considera o teste um sucesso de segurança e relata que a regra para aquela operação específica está corretamente configurada. Essa abordagem de teste real fornece uma validação concreta e confiável da eficácia das suas regras de segurança.