Checklist segurança web: 8 passos antes de lançar sua aplicação

Antes de apertar o botão de deploy, um checklist de segurança web pode separar um lançamento tranquilo de uma crise de madrugada. O objetivo aqui não é assustar, mas organizar: são oito passos verificáveis, agrupados em categorias, que qualquer equipe, mesmo sem um time de segurança dedicado, consegue percorrer em algumas horas. Use esta lista antes de cada release significativo, não apenas no MVP.

Autenticação e controle de acesso

1. Valide a autenticação em todos os endpoints

Verifique se rotas administrativas e áreas restritas exigem sessão ativa. Um erro comum é proteger o front-end mas esquecer APIs internas. Teste manualmente: tente acessar uma URL de admin sem login.

2. Autorização: o usuário certo no recurso certo

Não basta estar logado. Um usuário comum não deve acessar dados de outro. Implemente testes de autorização por papel (RBAC) e verifique se IDs em URLs não podem ser alterados manualmente (IDOR).

Criptografia e transporte

3. HTTPS ativo e redirecionamento forçado

Certifique-se de que todo o tráfego usa HTTPS, com certificado válido e renovação automática. Configure redirecionamento 301 de HTTP para HTTPS. Sem isso, senhas e tokens trafegam em texto puro.

4. Senhas armazenadas com hash forte

Nunca armazene senhas em texto plano. Use bcrypt, Argon2 ou PBKDF2. Se o banco vazar, o hash comprado compra tempo para os usuários trocarem credenciais.

Proteção contra injeção e XSS

5. Sanitização de entradas do usuário

Qualquer campo que aceita texto, formulários, URLs, uploads, pode ser vetor de ataque. Filtre e escape entradas contra SQL injection, XSS e command injection. Frameworks modernos ajudam, mas não substituem revisão manual.

6. Headers de segurança configurados

Headers HTTP como Content-Security-Policy (CSP), X-Content-Type-Options e Strict-Transport-Security bloqueiam classes inteiras de ataque. Use ferramentas como securityheaders.com para verificar se estão presentes.

Dependências e logs

7. Dependências atualizadas e sem vulnerabilidades conhecidas

Execute npm audit (ou equivalente no seu ecossistema) e corrija pacotes com falhas críticas. Bibliotecas desatualizadas são porta de entrada comum, como visto no ataque ao Equifax em 2017, causado por uma lib não atualizada.

8. Logs sem dados sensíveis e com monitoramento

Revise se logs de erro não expõem senhas, tokens ou chaves de API. Configure alertas para tentativas repetidas de login ou acessos a endpoints suspeitos. Log não monitorado é ruído, não segurança.

O erro mais comum ao usar este checklist

Acreditar que fazer uma vez é suficiente. Segurança não é evento, é processo. Muitas equipes aplicam o checklist no primeiro deploy e depois ignoram atualizações de dependências ou mudanças de configuração. Incorpore a verificação ao pipeline de CI/CD, com testes automatizados que falhem se headers sumirem ou certificados expirarem.

Perguntas frequentes sobre checklist de segurança web

O checklist substitui uma auditoria de segurança profissional?

Não. Este checklist cobre o mínimo operacional. Para aplicações que lidam com dados financeiros ou de saúde, uma auditoria externa e teste de penetração são recomendados.

Com que frequência devo revisar o checklist?

A cada deploy que envolva mudança de funcionalidade, dependência ou infraestrutura. No mínimo, uma vez por trimestre, mesmo sem alterações.

Preciso implementar tudo antes do primeiro lançamento?

Sim, especialmente HTTPS, autenticação, sanitização e headers. Os itens de logs e dependências podem ser refinados nos primeiros sprints, mas não deixe de fora criptografia e controle de acesso.

O que é IDOR e como testar?

IDOR (Insecure Direct Object Reference) ocorre quando um usuário acessa recurso de outro alterando um ID na URL. Teste manual: logue como usuário A, copie a URL de um recurso, logue como B e tente acessar.

Ferramentas automatizadas ajudam neste checklist?

Sim. Ferramentas como OWASP ZAP, SonarQube e Snyk automatizam parte das verificações. Use-as como complemento, não substituto da revisão manual.

Headers de segurança podem quebrar o funcionamento do site?

Sim, se mal configurados. Teste em ambiente de staging antes de aplicar em produção. Comece com políticas permissivas e restrinja gradualmente.