Erros Comuns em Web Security que Você Deve Evitar (Guia Definitivo)

Erros Comuns em Web Security que Você Deve Evitar (Guia Definitivo)

“`html





Erros comuns em Web Security que você deve evitar


Web Security
Guia prático (didático e técnico)

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) e
    SameSite abre 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.
Regra de ouro

Cookie de sessão com HttpOnly + Secure + SameSite, expiração definida, rotação após login
e revogação quando necessário.

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.
Prática recomendada

Use validação/serialização com esquemas (ex.: validação por campos obrigatórios, tipos, padrões e limites),
e aplique queries parametrizadas no banco.

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.
Como pensar

Para cada ação, valide: (1) identidade, (2) permissão, (3) escopo do recurso. Não “assuma” que o front trouxe o recurso correto.

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-ancestors facilita framing malicioso.
  • Erros detalhados em produção: stack traces e mensagens sensíveis expõem estrutura interna, facilitando exploração.
O que reduz risco com pouco esforço

Use CSP bem definida, cookies com atributos corretos, CSRF quando necessário e tratamento de erros sem vazamento.

Exemplo de headers (CSP + clickjacking + proteção de conteúdo)

# 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=...

Quer continuar evoluindo sua base de segurança?

Leia também outros posts sobre práticas seguras no desenvolvimento web: de autenticação e autorização até hardening de
infraestrutura e resposta a incidentes.


Ver outros posts



“`