Erros comuns em Web Security que você deve evitar
Se você desenvolve ou opera aplicações web, alguns deslizes aparecem em praticamente todo projeto. A boa notícia: quase todos têm correção objetiva. Abaixo, organizei os erros mais frequentes e como mitigar de forma segura.
1) Autenticação e sessão mal protegidas
Segurança em sessão é onde muita gente “deixa para depois”. Só que a superfície de ataque é direta: se o token/cookie vaza ou é possível reutilizar, o impacto vira conta comprometida.
-
Cookies sem atributos corretos: deixar de usar
HttpOnly,Secure(em produção) eSameSiteabre margem para roubo e ataques de navegação cruzada. - Persistência desnecessária: usar “Remember me” sem expirar, sem rotação e sem revogação torna a sessão eterna um alvo valioso.
- Rotação insuficiente de sessão: após login e mudança de privilégio, a sessão precisa ser regenerada. Caso contrário, existe risco de fixação de sessão.
- IDs previsíveis ou fracos: usar identificadores de sessão/tokens que podem ser adivinhados piora tudo. Tokens precisam ser aleatórios e longos o suficiente.
2) Não validar entrada (e confiar no front-end)
A validação precisa existir no servidor. O navegador ajuda, mas não impede um atacante de mandar requisições “inventadas”. Esse erro costuma abrir espaço para injeções, abuso de lógica e falhas de autorização.
- Validação apenas no client: qualquer regra aplicada só no JavaScript é facilmente contornada.
- SQL/NoSQL injection por concatenação: montar queries com strings vindas do usuário é convite direto.
- Sem normalização de dados: input com espaços, caracteres invisíveis, encodings diferentes e formatos inesperados pode “burlar” validações superficiais.
- Falta de tratamento de tipo e limites: não limitar tamanho de payload, não definir limites de paginação e aceitar campos mal tipados vira vetor de DoS e comportamento inesperado.
3) Autorização inexistente ou inconsistente
Autenticação diz “quem é você”. Autorização diz “o que você pode fazer”. É muito comum existir login, mas não existir controle real de acesso em cada rota/ação.
- Confundir “estar logado” com “ter permissão”: endpoints que apenas checam sessão, mas não verificam escopo (tenant, empresa, projeto, recurso).
- Falhas por IDOR: usar IDs em URLs sem checar ownership/permissão permite acesso a recursos de terceiros.
- Regras duplicadas em lugares diferentes: quando a lógica de autorização fica espalhada, surge divergência. O resultado é “uma rota valida e outra não”.
- Ausência de testes de segurança: sem casos cobrindo permissões (usuário A não acessa recurso do usuário B), o erro reaparece.
4) Headers e tratamento de conteúdo ausentes (XSS/CSRF e exfiltração)
Muitas aplicações “funcionam” sem falhar visivelmente, mas ficam expostas a ataques comuns. Aqui entram XSS, CSRF, clickjacking e políticas de segurança do navegador negligenciadas.
- XSS por escape insuficiente: inserir conteúdo do usuário sem escaping/validação transforma o app em um “refletor” de scripts.
- CSRF sem proteção: não usar tokens anti-CSRF (quando aplicável) e/ou não adotar políticas de cookie adequadas.
- Sem Content Security Policy (CSP): quando você não restringe fontes, qualquer XSS tem mais liberdade de execução.
-
Falta de anti-clickjacking: ausência de
X-Frame-Options/frame-ancestorsfacilita framing malicioso. - Erros detalhados em produção: stack traces e mensagens sensíveis expõem estrutura interna, facilitando exploração.
# Exemplo (ajuste para seu domínio e rotas)
# Preferir configuração no reverse proxy (Nginx/Traefik/Cloudfront) ou framework.
# Objetivo: reduzir XSS/CSRF/clickjacking com políticas explícitas.
Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none';
frame-ancestors 'none';
script-src 'self'; style-src 'self' 'unsafe-inline';
img-src 'self' data:; font-src 'self';
upgrade-insecure-requests;
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
# Anti clickjacking (se não usar frame-ancestors na CSP)
X-Frame-Options: DENY
# Se você usa cookies: configure também
# Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=...