Seu app funciona. Agora feche as 6 portas.

01Prompt completo

Copie tudo e cole no Claude Code, na raiz do projeto.

Atue como engenheiro de segurança de aplicações revisando ESTE repositório antes de ir para produção. Pense como um invasor que abre o app pelo navegador, mas trabalhe só no código e no histórico deste projeto: não faça requisição para sistemas de terceiros.

Regras de trabalho:
- Antes de mudar qualquer arquivo, liste o que encontrou em cada porta, com arquivo e linha, e classifique como CRÍTICO, ALTO ou OK.
- Corrija uma porta por vez. Depois de cada uma, rode os testes e mostre o diff.
- Não apague nem reescreva o histórico do Git sem eu pedir. Não troque chaves por mim: me diga quais trocar e onde.

---

### PORTA 1: O NAVEGADOR (chave no front-end)
1. Procure chaves, tokens e senhas em tudo que vai para o navegador: código do cliente, bundle gerado, variáveis públicas (`NEXT_PUBLIC_`, `VITE_`, `REACT_APP_`, `PUBLIC_`) e arquivos estáticos.
2. Toda chave secreta (pagamento, LLM, e-mail, service role do banco) sai do cliente e passa a ser usada só numa rota do servidor.
3. Chave pública que precisa ficar no cliente (ex.: anon key do Supabase) só é aceitável se o banco tiver regra de acesso (RLS) em todas as tabelas. Confira.

### PORTA 2: O FORMULÁRIO (injeção no banco)
1. Encontre toda consulta montada com concatenação ou template string a partir de dado do usuário.
2. Troque por consulta parametrizada ou pelo método do ORM/SDK que já trata o valor como dado.
3. Valide no servidor tipo, tamanho e formato de todo campo recebido (ex.: Zod), mesmo que o front já valide.

### PORTA 3: O LOGIN (força bruta)
1. Coloque rate limit no login, no cadastro, na recuperação de senha e no envio de código: limite por IP e por conta, com resposta 429.
2. A mensagem de erro do login não diz se foi o e-mail ou a senha que errou.
3. Se o login for próprio, a senha é guardada com bcrypt ou argon2. Se usar provedor (Supabase Auth, Clerk, Auth0), confirme que a proteção contra força bruta dele está ligada.

### PORTA 4: A URL (rota de admin escondida)
1. Liste todas as rotas e endpoints. Para cada um, diga quem pode acessar.
2. Toda rota de admin e toda API checa sessão e permissão NO SERVIDOR. Esconder botão ou link não conta.
3. Confira acesso a recurso de outro usuário: trocar o id na URL (`/pedido/123` para `/pedido/124`) não pode mostrar dado de outra pessoa.

### PORTA 5: O PREÇO (valor vindo do navegador)
1. Encontre todo lugar em que o servidor aceita preço, desconto, frete, quantidade de crédito ou papel do usuário vindo do cliente.
2. O servidor recalcula o valor a partir do id do produto e das regras dele. O cliente manda só o que o usuário escolheu.
3. Webhook de pagamento tem a assinatura conferida antes de liberar qualquer coisa.

### PORTA 6: O GIT (segredo no histórico)
1. Procure segredos em todo o histórico, não só nos arquivos atuais (ex.: `git log -p` ou gitleaks, se estiver instalado).
2. Liste cada segredo encontrado, o commit e o serviço dele. Chave que esteve no histórico conta como vazada: me diga onde trocar.
3. Confirme que `.env` e arquivos de credencial estão no `.gitignore` e deixe um `.env.example` sem valores.

---

### ENTREGA
Uma tabela final com as 6 portas: o que estava aberto, o que foi corrigido, o que depende de mim (trocar chave, ligar proteção no painel) e o teste que prova cada correção.

02Confira depois

Marque o que já ficou fechado.