Testes de segurança antes de produção são a última barreira entre o código e o usuário final. Eles identificam vulnerabilidades que podem custar caro depois do deploy. Este checklist serve para equipes que vão publicar um sistema, seja uma atualização ou um produto novo. Aplique-o na fase final do desenvolvimento, quando as funcionalidades já estão estáveis.
Autenticação e controle de acesso
- Revise permissões de usuário: cada papel deve acessar apenas o que precisa. Um usuário comum não pode enxergar rotas de administrador.
- Teste sessões e tokens: verifique se tokens expiram e se sessões são invalidadas no logout. Sessão que não expira é porta de entrada para acesso indevido.
- Confira a recuperação de senha: o fluxo de redefinição não pode permitir alteração de senha de outro usuário. Teste com duas contas diferentes.
Dependências e bibliotecas
- Atualize bibliotecas com vulnerabilidades conhecidas: use ferramentas de varredura como npm audit ou OWASP Dependency-Check. Uma dependência desatualizada pode anular todos os outros testes.
- Remova pacotes não utilizados: código morto aumenta a superfície de ataque. Menos dependências, menos riscos.
Configuração de ambiente
- Desative o modo de depuração: em produção, mensagens de erro detalhadas revelam estrutura interna do sistema. Ative apenas logs essenciais.
- Verifique variáveis de ambiente: senhas e chaves de API não podem estar no código-fonte. Use um gerenciador de segredos.
- Confira cabeçalhos HTTP: headers como Content-Security-Policy e X-Frame-Options ajudam a mitigar ataques de injeção e clickjacking.
Entrada de dados e logs
- Teste entradas maliciosas: envie payloads com caracteres especiais e scripts. Validar e sanitizar entradas previne injeção de SQL e XSS.
- Revise logs: logs não podem conter dados sensíveis, como senhas ou números de cartão. Informações expostas em log viram material para atacantes.
- Limite taxas de requisição: endpoints de login e API devem ter limite de tentativas. Isso reduz força bruta e ataques de negação de serviço.
O erro mais comum
O erro mais comum é tratar os testes de segurança como etapa opcional, feita às pressas um dia antes do deploy. Equipes pulam a revisão de permissões ou testam apenas o fluxo feliz. O resultado é um sistema que funciona, mas está exposto. Reserve tempo no cronograma para essa etapa. Um dia de testes pode evitar semanas de correção após um incidente.
Perguntas frequentes
Quando devo fazer testes de segurança?
Faça na última etapa do desenvolvimento, antes do deploy em produção. Se o sistema já está no ar, realize os testes em um ambiente de homologação que espelhe a configuração real.
Preciso contratar uma empresa especializada?
Depende do risco do sistema. Para aplicações que lidam com dados financeiros ou de saúde, um pentest externo é recomendado. Para projetos internos, um checklist bem aplicado já reduz boa parte dos riscos.
O que é um teste de vulnerabilidade?
É uma varredura automatizada ou manual que procura falhas conhecidas no código, nas dependências e na configuração. Ferramentas como OWASP ZAP e Burp Suite ajudam a identificar esses pontos.
Testes de segurança atrasam o lançamento?
Podem atrasar se forem feitos em cima da hora. Quando integrados ao fluxo de desenvolvimento, os testes se tornam parte do processo e não geram retrabalho significativo.
Qual a diferença entre teste de segurança e teste funcional?
O teste funcional verifica se o sistema faz o que deveria. O teste de segurança verifica se o sistema resiste a tentativas de uso indevido. São complementares, mas objetivos diferentes.
Como saber se meu checklist está completo?
Compare com padrões como OWASP Top 10 e revise o checklist a cada novo recurso lançado. O que funciona hoje pode não cobrir uma funcionalidade nova amanhã. Ajuste o documento continuamente.