Fez site com IA? Roda isso antes de publicar

Aja como um engenheiro sênior de segurança de aplicações.

Faça uma auditoria de segurança desta aplicação antes de ela ir para produção.

IMPORTANTE:
- Não assuma que a aplicação é segura só porque ela funciona.
- Não dê apenas conselhos genéricos de segurança.
- Inspecione de verdade o código, as configurações, as regras do banco de dados, os fluxos de autenticação, as rotas de API, a configuração de storage, o uso de variáveis de ambiente, as dependências e a configuração de deploy.
- Não faça mudanças destrutivas nem mexa em sistemas de produção sem a minha aprovação explícita.
- Nunca mostre nem exponha segredos reais na sua resposta.

Use como base o OWASP Top 10, o guia de segurança de API da OWASP e as boas práticas de segurança de cada plataforma usada.

AUDITE O SEGUINTE:

1. SEGREDOS E CHAVES DE API
- Procure no repositório inteiro e no histórico do Git por chaves de API, tokens, senhas, chaves privadas, URLs de banco de dados, chaves de service role e outros segredos.
- Confira os arquivos .env e confirme que os .env sensíveis estão ignorados pelo Git.
- Identifique segredos que foram expostos no lado do cliente por engano.
- Diferencie chaves públicas, seguras para o cliente, de segredos privilegiados que só podem ficar no servidor.
- Se algum segredo já foi commitado, me avise que apagar o arquivo não basta e recomende trocar ou revogar a chave.

2. AUTENTICAÇÃO
- Revise cadastro, login, logout, recuperação de senha, OAuth, sessões, cookies, uso de JWT e armazenamento de tokens.
- Confira se a autenticação é realmente exigida no servidor.
- Procure enumeração de contas, recuperação de senha fraca, sessões inseguras e formas de burlar a autenticação.
- Confira proteção contra força bruta e limite de tentativas onde fizer sentido.

3. AUTORIZAÇÃO
- Não assuma que estar logado significa ter permissão.
- Inspecione toda rota de API e server action sensível.
- Verifique no servidor quem é dono de cada recurso e quais permissões ele tem.
- Teste se o Usuário A consegue ler, alterar, apagar, baixar ou atualizar recursos do Usuário B só trocando um ID.
- Confira separadamente as funções que só o admin pode usar.
- Procure especificamente IDOR/BOLA e autorização quebrada por função.

4. SEGURANÇA DO BANCO DE DADOS
- Revise as permissões do banco.
- Se usar Supabase, inspecione as políticas de Row Level Security de toda tabela, view e função exposta e confirme que chaves privilegiadas ou de service role nunca chegam ao cliente.
- Se usar Firebase, inspecione as Security Rules do Firestore, do Realtime Database e do Storage e procure acesso de leitura ou escrita amplo demais.
- Verifique o isolamento de dados entre usuários e entre clientes.

5. SEGURANÇA DA API
- Liste todas as rotas de API, server actions, webhooks, funções RPC e endpoints.
- Confira autenticação e autorização de cada endpoint sensível.
- Valide no servidor todo parâmetro que vem de fora.
- Confira limites de uso em autenticação, endpoints caros, uploads, mensagens, chamadas de IA, ações de pagamento e outras operações que podem ser abusadas.
- Procure SSRF e uso inseguro de APIs de terceiros onde fizer sentido.

6. ENTRADA DE DADOS E INJEÇÃO
- Procure injeção de SQL e NoSQL.
- Procure XSS, injeção de comando, injeção de template, path traversal e consultas dinâmicas inseguras onde se aplicar.
- Prefira consultas parametrizadas.
- Valide as entradas no servidor.
- Codifique ou limpe o conteúdo controlado pelo usuário de acordo com o lugar onde ele aparece.

7. UPLOAD DE ARQUIVOS E STORAGE
- Revise os endpoints de upload.
- Limite o tamanho e os tipos de arquivo aceitos.
- Não confie só no nome do arquivo nem no tipo informado pelo navegador.
- Gere nomes seguros para salvar os arquivos.
- Impeça path traversal e acesso não autorizado a arquivos.
- Revise as permissões dos buckets e do storage.

8. LIMITES DE CONFIANÇA NO FRONTEND
- Trate tudo que roda no navegador como controlado por um atacante.
- Encontre decisões de segurança que estão só no código do frontend.
- Verifique de novo, no servidor ou no banco, as checagens de permissão sensíveis.
- Confirme que nenhuma credencial privilegiada foi empacotada no JavaScript do frontend.

9. ROTAS DE ADMIN
- Encontre painéis de admin, APIs de admin, ferramentas de moderação, endpoints internos e ações privilegiadas.
- Verifique as checagens de papel e permissão no servidor.
- Tente identificar formas de um usuário comum logado conseguir acionar essas funções.

10. CONFIGURAÇÃO DE SEGURANÇA
- Confira a configuração de CORS.
- Revise os headers de segurança relevantes.
- Confira as flags dos cookies onde se aplicar.
- Garanta que o modo debug está desligado em produção.
- Impeça que stack traces, caminhos internos, erros do banco, segredos e detalhes de implementação cheguem ao usuário.

11. DEPENDÊNCIAS E CADEIA DE FORNECIMENTO
- Inspecione as dependências atrás de vulnerabilidades conhecidas e pacotes desnecessários.
- Revise os lockfiles.
- Aponte pacotes sensíveis para segurança que estejam desatualizados ou arriscados.
- Confira os workflows de CI/CD atrás de uso inseguro de segredos ou de entradas não confiáveis.

12. LOGS E MONITORAMENTO
- Confirme que tentativas de login que falharam e eventos importantes de segurança podem ser monitorados.
- Garanta que informações sensíveis, senhas, tokens de acesso, headers de autorização e dados pessoais desnecessários não vão para os logs.
- Recomende alertas de segurança para comportamento suspeito onde fizer sentido.

13. CONFIGURAÇÃO DE PRODUÇÃO
- Procure configurações de desenvolvimento ligadas por engano em produção.
- Revise a separação entre ambientes.
- Confira a exposição do banco de dados e do storage.
- Revise os arquivos de configuração específicos do deploy.

14. TESTE DO ATACANTE
Assuma que você é:
A) alguém sem login,
B) um usuário comum logado,
C) um usuário mal-intencionado tentando acessar dados de outra pessoa.

Para cada papel, diga quais ações sensíveis você tentaria e se a implementação atual impede cada uma delas.

FORMATO DA RESPOSTA:

Comece com:

RESUMO DA AUDITORIA DE SEGURANÇA
Crítico:
Alto:
Médio:
Baixo:

Depois, para cada problema encontrado, traga:

Problema:
Gravidade:
Local/Arquivo:
Evidência:
Por que importa:
Como poderia ser explorado:
Correção recomendada:
Teste de verificação:

Não diga que algo está vulnerável sem ter evidência no código ou na configuração. Se não tiver certeza, marque claramente como algo que precisa de verificação manual.

Depois dos problemas, traga:

CHECKLIST DE SEGURANÇA ANTES DE PUBLICAR

Use:
[OK]
[FALHOU]
[PRECISA DE REVISÃO MANUAL]

Por fim, traga:

AS 5 COISAS QUE EU PRECISO CORRIGIR ANTES DE PUBLICAR

Priorize problemas exploráveis envolvendo:
- segredos expostos
- autenticação quebrada
- autorização quebrada
- acesso a dados de outros usuários
- banco de dados ou storage expostos
- acesso de admin
- injeção
- operações caras sem limite

Não marque a aplicação como "segura" só porque não encontrou problemas óbvios. Explique o que ainda precisa de teste de invasão manual ou de verificação em produção.