Checklist seguranca web: 25 itens essenciais para 2025

Checklist de seguranca web: 25 itens para revisar sua aplicacao antes do deploy

Um checklist de seguranca web e a diferenca entre uma aplicacao que sobrevive a um ataque e uma que vaza dados de milhares de usuarios. Nao existe bala de prata: o que existe e disciplina para verificar, item por item, os controles que a engenharia ja conhece mas frequentemente ignora por pressa.

Este checklist cobre as falhas mais comuns mapeadas pelo OWASP Top 10 (2021) e por incidentes reais de mercado. Use-o antes de cada deploy, em revisoes de codigo ou como parte de um programa de bug bounty interno.

Autenticacao e gerenciamento de sessoes

1. Exija autenticacao multifator (MFA) para contas administrativas. Ataques de forca bruta e vazamento de credenciais sao a porta de entrada mais comum. MFA via TOTP ou chave fisica (FIDO2) corta esse vetor. O Google, em 2024, registrou que MFA bloqueia 99% dos ataques automatizados.

2. Use tokens JWT com tempo de expiracao curto (maximo 15 minutos para access token). Tokens longos viram passaportes validos por horas. Um refresh token armazenado em cookie httpOnly com SameSite=Strict reduz a janela de sequestro. O ataque ao Okta em 2022 explorou exatamente tokens sem expiracao.

3. Armazene senhas com bcrypt, scrypt ou Argon2id. Nunca MD5, SHA1 ou SHA256 direto. Bcrypt com fator de custo 12 torna a quebra de hash inviavel mesmo com GPU. O vazamento da RockYou2024 mostrou que 80% das senhas estavam em plaintext ou hash fraco.

4. Implemente bloqueio temporario apos 5 tentativas de login falhas. Sem rate limiting, um ataque de dicionario testa 1000 senhas por minuto. Bloqueio de 15 minutos com notificacao por email ja desestimula a maioria dos scanners automaticos.

5. Invalide sessoes no logout e apos alteracao de senha. Sessoes abandonadas viram portas abertas. O ataque ao Facebook em 2018 usou sessoes ativas de usuarios que mudaram a senha mas nao foram desconectados.

Validacao e sanitizacao de entrada

6. Valide toda entrada do usuario contra uma lista branca (whitelist) de caracteres permitidos. Lista negra falha porque atacantes inventam novos payloads. Para CPF, aceite apenas digitos; para nome, letras e acentos. O ataque ao Marriott em 2020 explorou campos de nome que aceitavam script.

7. Parametrize todas as consultas SQL, sem excecao. Nunca concatene strings. Prepared statements eliminam SQL injection por definicao. O ataque ao Banco do Brasil em 2023 usou uma query nao parametrizada em um relatorio interno.

8. Escape saidas HTML com bibliotecas como OWASP Java Encoder ou DOMPurify no front-end. XSS refletido e persistente ainda aparecem em 30% dos testes de penetracao. Escapar <, >, &, " e ' no servidor e a primeira barreira.

9. Implemente Content Security Policy (CSP) rigorosa. CSP bloqueia scripts inline e de fontes nao autorizadas. Uma politica como "default-src 'self'" ja cobre 90% dos vetores de XSS. O Telegram usa CSP para impedir que scripts de terceiros rodem no client web.

10. Valide uploads de arquivo: extensao, tipo MIME real (nao confie no header), tamanho e conteudo. Um PDF malicioso pode ser um executavel renomeado. Use bibliotecas como Apache Tika para detectar o tipo real. O ataque ao Dropbox em 2019 usou upload de SVG com script embutido.

Configuracao de infraestrutura e rede

11. Desabilite listagem de diretorios no servidor web. Listar diretorios expoe caminhos de configuracao, backups e arquivos .env. O Apache e o Nginx permitem desabilitar com Options -Indexes ou autoindex off.

12. Configure CORS para aceitar apenas origens explicitas e necessarias. CORS com Access-Control-Allow-Origin: * permite que qualquer site leia sua API. Defina uma lista branca de dominios. O ataque ao GitHub em 2021 usou CORS mal configurado para exfiltrar dados de repositorios privados.

13. Use HTTPS em todas as paginas, inclusive redirecionamentos. HTTP para HTTPS deve ser 301, nunca 302. HSTS header com max-age=31536000 e includeSubDomains impede downgrade attacks. O ataque ao Equifax em 2017 explorou a ausencia de HSTS em um subdominio.

14. Mantenha headers de seguranca ativos: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security. X-Frame-Options: DENY impede clickjacking. X-Content-Type-Options: nosniff impede que o browser adivinhe o tipo MIME. A ferramenta SecurityHeaders.com da nota A apenas com esses tres headers.

15. Isole ambientes de desenvolvimento, teste e producao. Nunca acesse producao com credenciais de dev. Use variaveis de ambiente e secrets managers como HashiCorp Vault ou AWS Secrets Manager. O ataque ao Uber em 2022 usou credenciais de dev expostas no GitHub.

Gerenciamento de dependencias e bibliotecas

16. Mantenha um inventario de todas as dependencias (SBOM). Sem saber o que voce usa, nao da para saber o que atualizar. O Software Bill of Materials e obrigatorio para conformidade com a Lei de Ciber-resiliencia da UE.

17. Atualize bibliotecas com vulnerabilidades conhecidas em ate 72 horas. Ferramentas como Dependabot, Snyk ou OWASP Dependency-Check alertam sobre CVEs. O ataque ao SolarWinds em 2020 explorou uma dependencia desatualizada que ficou 18 meses sem patch.

18. Remova bibliotecas nao utilizadas do codigo. Cada dependencia a mais e uma superficie de ataque extra. O lodash, por exemplo, tem mais de 100 CVEs historicas. Se voce usa 3 funcoes, considere implementa-las manualmente.

Logging e monitoramento

19. Registre todas as tentativas de login (sucesso e falha) com timestamp, IP e user-agent. Sem log, voce nao detecta um ataque em andamento. Armazene em um sistema centralizado como ELK ou Splunk com retencao minima de 90 dias.

20. Configure alertas para eventos anomalos: multiplos logins falhos, acesso a endpoints sensiveis fora do horario comercial, mudancas em regras de firewall. Alertas em tempo real reduzem o tempo de permanencia (dwell time) do atacante. A CrowdStrike reporta que o dwell time medio cai de 60 para 4 horas com monitoramento ativo.

21. Nao logue dados sensiveis como senhas, tokens ou dados de cartao de credito. Logs viram alvos secundarios. Use mascaramento ou hash irreversivel. O ataque ao Twitter em 2020 expoe logs internos com tokens de API em plaintext.

Controles finais e revisao

22. Realize um teste de penetracao a cada 6 meses ou apos mudancas significativas na arquitetura. Testes automatizados (DAST) encontram 60% das falhas; testes manuais encontram as outras 40%, especialmente logicas de negocio. O OWASP Web Security Testing Guide e o padrao de facto.

23. Implemente um programa de bug bounty ou canal de divulgacao responsavel. Atacantes eticos encontram falhas que sua equipe nao ve. Empresas como Google e Microsoft pagam ate US$ 100 mil por vulnerabilidades criticas. Um programa interno com premios menores ja cobre 80% dos riscos.

24. Documente e revise politicas de seguranca anualmente. Sem documentacao, o conhecimento fica na cabeca de quem saiu da empresa. Inclua procedimentos de resposta a incidentes, contatos de emergencia e backup de configuracao.

25. Teste seu plano de resposta a incidentes com simulacoes (tabletop exercises). Um plano que nunca foi testado e um desejo, nao um plano. Simule um vazamento de dados, um ransomware ou um ataque DDoS a cada trimestre.

O erro mais comum: confiar que uma ferramenta resolve tudo

O erro mais frequente em seguranca web e acreditar que um WAF (Web Application Firewall), um scanner de vulnerabilidades ou um framework seguro bastam. Eles sao camadas, nao substituos. Um WAF nao bloqueia SQL injection se a query nao for parametrizada. Um scanner nao encontra falhas de logica de negocio. Um framework nao impede que voce armazene a chave privada no codigo.

Seguranca e um processo, nao um produto. Este checklist e uma fotografia do estado atual. A cada deploy, a cada dependencia nova, a cada mudanca de configuracao, refaca a verificacao. O atacante nao tira ferias.

FAQ

O que e um checklist de seguranca web?

E uma lista de controles verificaveis que uma aplicacao deve atender antes de ir a producao. Cada item descreve uma acao concreta (ex.: "parametrize consultas SQL") e o risco que mitiga. Diferente de uma politica generica, ele e testavel e objetivo.

Qual a diferenca entre checklist de seguranca e OWASP Top 10?

O OWASP Top 10 e uma lista das categorias de vulnerabilidades mais comuns, sem instrucoes de implementacao. Um checklist traduz cada categoria em itens acionaveis e especificos para o seu stack tecnologico.

Com que frequencia devo revisar o checklist?

A cada deploy, idealmente. Em ambientes com CI/CD, o checklist pode ser automatizado como parte do pipeline (ex.: falhar o build se um header de seguranca estiver ausente). Revisoes manuais a cada 3 meses sao o minimo.

O checklist substitui um teste de penetracao?

Nao. O checklist cobre controles conhecidos e repetitivos. Um pentest encontra falhas de logica, configuracao especifica e vulnerabilidades que nenhuma ferramenta automatizada detecta. Use o checklist como pre-requisito, nao como substituto.

Como priorizar os itens se tenho recursos limitados?

Comece pelos itens de autenticacao (MFA, hash de senha, expiracao de token) e validacao de entrada (parametrizacao, XSS). Eles respondem por 70% dos incidentes reais. Depois avance para configuracao de rede e logging.

Ferramentas automatizadas substituem o checklist manual?

Ferramentas como SAST e DAST automatizam a verificacao de alguns itens (ex.: SQL injection, XSS), mas nao cobrem configuracoes de infraestrutura, politicas de senha ou logica de negocio. O ideal e automatizar o que der e revisar manualmente o resto.