Checklist de segurança web antes de lançar (2026)

Lançar é a hora em que sua aplicação vira alvo. Bots varrem a internet inteira atrás de portas abertas, headers ausentes e senhas fracas — e a maioria dos incidentes começa por algo trivial que ninguém revisou antes do deploy. Este checklist cobre o que barra o ataque oportunista. Passe grupo por grupo; cada item é uma pergunta de sim ou não.

O checklist

1. Transporte & headers

• HTTPS em tudo — certificado válido, redirect automático de HTTP para HTTPS, sem conteúdo misto (mixed content).
• HSTS ligado — header Strict-Transport-Security com max-age longo, para o navegador nunca cair de volta em HTTP.
• CSP definida — Content-Security-Policy restringindo de onde scripts, estilos e frames podem carregar (a defesa mais forte contra XSS).
• X-Content-Type-Options: nosniff — impede o navegador de adivinhar tipos de conteúdo e executar o que não devia.
• Cookies endurecidos — flags Secure, HttpOnly e SameSite em todo cookie de sessão.
• Headers extras: Referrer-Policy, X-Frame-Options (ou frame-ancestors na CSP) contra clickjacking.

2. Autenticação & sessão

• Senhas com hash forte — bcrypt, scrypt ou Argon2. Nunca MD5, SHA1 puro ou texto plano.
• Política de senha mínima — comprimento razoável e bloqueio de senhas vazadas conhecidas.
• MFA disponível — ao menos para contas administrativas e, de preferência, oferecido a todos os usuários.
• Sessão com expiração — timeout de inatividade, invalidação no logout e rotação do token após login.
• Proteção contra brute force — rate limiting no login, lockout progressivo ou captcha após tentativas falhas.
• Sem IDOR — toda rota que acessa um recurso por ID valida se o usuário logado tem direito àquele recurso (não confie só no ID vindo do cliente).

3. Entrada & saída

• Validação por allowlist — valide todo input contra o que é permitido, não contra o que é proibido. Aplique no servidor, não só no front.
• Prevenção de XSS — escape na saída por contexto (HTML, atributo, JS) e CSP como segunda camada.
• Prevenção de SQL injection — queries parametrizadas / prepared statements em todo acesso a banco. Nunca concatene input em SQL.
• Upload seguro — valide tipo e tamanho, gere nome próprio no servidor, armazene fora da raiz web e nunca execute o que foi enviado.
• Trate também injeção em comandos de sistema, templates e cabeçalhos.

4. Infra & segredos

• Segredos em variáveis de ambiente — chaves, tokens e senhas fora do código, injetados no runtime.
• Nenhum segredo no repositório — nem no histórico do Git. Verifique com um scanner de segredos e rotacione o que já vazou.
• Menor privilégio — o app roda com o usuário e as permissões mínimas; o usuário do banco não é superusuário.
• Rate limiting global — limite requisições por IP/conta nas rotas sensíveis (login, APIs, reset de senha).
• WAF / proxy na frente — Cloudflare, Traefik ou similar para filtrar tráfego malicioso óbvio antes de chegar na app.
• Portas de banco, cache e administração fechadas para a internet — acesso só pela rede interna.

5. Dependências & superfície

• Scan de dependências — rode npm audit, Dependabot ou equivalente e atualize pacotes com CVE conhecida.
• Rotas de debug removidas — endpoints de teste, painéis internos e consoles de admin expostos por engano saem antes do go-live.
• Erros discretos — nada de stack trace, versão de framework ou query no banco vazando na tela do usuário. Log detalhado fica no servidor.
• Superfície mínima — desative features, métodos HTTP e integrações que você não usa.
• Remova credenciais e contas padrão de qualquer serviço.

6. Observabilidade & recuperação

• Logs de segurança — logins, falhas de auth, ações administrativas e erros ficam registrados (e sem dados sensíveis em texto plano).
• Alertas configurados — alguém é avisado quando algo anormal acontece (pico de erros, tentativas de login, uso de CPU/disco).
• Backups testados — backup automático e, o mais importante, um restore que você já validou de verdade. Backup nunca testado não é backup.
• Plano de incidente — quem faz o quê se algo vazar: como revogar acesso, avisar usuários e conter o dano.

7. Validação final

• Rodar um pentest antes do go-live — não basta ter os controles no papel; valide que eles seguram um ataque de verdade.
• Corrija o que o pentest achou e rode de novo antes de abrir ao público.
• Re-teste a cada mudança relevante — segurança não é evento único, é rotina.

Resumo: risco × item

Marcar os itens não é o mesmo que estar seguro

Este checklist te tira da faixa do ataque preguiçoso — que é a maioria. Mas um Content-Security-Policy mal configurado ainda deixa passar XSS, e uma autorização que parece correta pode ter um IDOR escondido em uma rota específica. A única forma de saber se os controles seguram é atacá-los de verdade.

É aí que entra a validação final. O Escudo Code é o pentest automatizado que explora de verdade: executa exploits reais contra a sua aplicação, confirma cada achado com evidência e severidade CVSS, e descarta o que não se confirma. Rode antes do lançamento para fechar o checklist com dado, não com suposição — veja como testamos ou os planos.

Depois do go-live, o próximo passo é tornar isso rotina: teste seu SaaS a cada deploy e entenda o que é um pentest na prática.