Checklist de segurança antes de publicar seu app

Banco de dados

1. Row Level Security em toda tabela. No Supabase, nenhuma tabela do schema public com RLS desligado. No Firebase, Security Rules que negam por padrão.
2. Políticas testadas sem login. Chamar a API do banco com a chave pública e receber lista vazia em toda tabela privada.
3. Políticas testadas entre usuários. Logado como usuário A, pedir um registro do usuário B e receber nada.
4. Arquivos privados. Buckets privados por padrão; links de arquivo sensível com expiração.

Chaves e segredos

5. Nenhum segredo no navegador. Buscar service_role, sk-, sk_live e secret no pacote publicado (DevTools, Sources).
6. Nenhum segredo no histórico. Varredura do repositório inteiro, inclusive commits antigos, com Gitleaks.
7. Chaves vazadas revogadas. Toda chave que já esteve publicada foi trocada no painel do serviço, não só apagada do código.

Login e sessão

8. Limite de tentativas. Login, reset de senha, cupom e envio de e-mail com limite por usuário e por IP.
9. Reset de senha seguro. Link que expira, uso único e mensagem igual para e-mail cadastrado ou não.
10. Cadastro sob controle. Cadastro fechado se o app for só para convidados; confirmação de e-mail ligada.
11. MFA para administradores. Toda conta com poder de administração usa segundo fator.

Permissões

12. Permissão conferida no servidor. Ação de administrador repetida como usuário comum (copiando a requisição) precisa falhar.
13. Sem acesso a dados de outro cliente. Trocar IDs em toda requisição e receber só o que é seu.
14. Valores calculados no servidor. Preço, desconto e saldo nunca aceitos do navegador.

Publicação

15. Sem source maps em produção. Nenhum arquivo .map acessível no site publicado.
16. Cabeçalhos de segurança. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options e X-Frame-Options.
17. CORS restrito. A API aceita chamadas só das origens do seu app.

Operação

18. Backup testado. Backup automático ligado e uma restauração feita de verdade.
19. Logs e alerta. Falhas de login em massa e leituras anormais deixam registro e geram aviso.
20. Dependências sem falha crítica. npm audit (ou similar) sem vulnerabilidade crítica em função que o app usa.

Quando chamar uma auditoria

O checklist pega o que é visível de fora. Ele não substitui um teste das regras do seu negócio por alguém que não escreveu o código. Vale chamar uma auditoria antes de abrir o app para clientes reais, quando ele guarda dados pessoais, de saúde ou de pagamento, ou quando um cliente ou investidor pede prova de segurança.

Para apps com Supabase ou Firebase, o Diagnóstico Express cobre os itens críticos deste checklist em até 5 dias úteis, com prova e correção recomendada.