Erros Comuns em OWASP: O Que Você Deve Evitar para Melhorar a Segurança

Erros Comuns em OWASP: O Que Você Deve Evitar para Melhorar a Segurança

“`html





Erros comuns em OWASP que você deve evitar

OWASP • checklist prático para evoluir seu app com segurança

Erros comuns em OWASP que você deve evitar

Eu gosto de tratar segurança como engenharia: menos “sustos”, mais decisões claras. Abaixo estão falhas recorrentes
que fazem aplicações passarem em revisão superficial e quebrarem na prática — exatamente o tipo de coisa que o
OWASP ajuda a expor.

1Autenticação fraca e sessão mal gerida (A01/2021 — Broken Access Control e correlatos)

Muitos projetos tentam resolver segurança “na camada do front” ou assumem que o backend “vai conferir tudo”.
Quando a sessão e o controle de acesso ficam frouxos, surgem vazamentos de dados e ações não autorizadas.

  • Confiar apenas no estado do cliente: ocultar botões não impede que endpoints sejam chamados.
  • Ausência de autorização por recurso: autenticar não é o mesmo que permitir “o que” o usuário pode fazer.
  • Reutilização indevida de tokens/cookies: manter sessão longa sem rotação aumenta impacto de roubo.
  • Falta de proteção contra fixação de sessão: não regenerar sessão após login é um erro clássico.
  • Controle de acesso inconsistente: algumas rotas protegem, outras “esquecem” e viram bypass.

Regra de ouro: todo request sensível precisa validar autorização no servidor para o recurso alvo
(ex.: “este usuário pode ler/alterar este ID?”), não apenas “está logado?”.

2Injeções e validação insuficiente (A03/2021 — Injection)

Injeção não é só “SQL”. É qualquer lugar onde dados do usuário viram instrução/parte de um comando:
SQL, NoSQL, comandos do sistema, templates, filtros, ordenações e até partes de URL usadas no backend.

  • Montar queries com concatenação (SQL/NoSQL) em vez de parametrizar.
  • Validar “apenas o formato” e esquecer de restringir intenção (ex.: aceitar qualquer caractere).
  • Permitir ordenação/filtros arbitrários sem whitelist de campos e operadores.
  • Escapar inconsistentes: às vezes aplica no HTML, mas esquece em logs, cabeçalhos ou templates.
  • Interagir com dependências inseguras: montar comandos/filtrar com entradas sem sanitização.

Regra prática: trate toda entrada como não confiável. Use parametrização e whitelists para
qualquer “parte estrutural” (colunas, nomes de campos, ordenações, operadores, paths).

3CSRF e falta de proteção de requisições privilegiadas (A01/2021 e padrões de segurança de sessão)

Segurança moderna não depende só de “login”. Se o navegador da vítima consegue enviar requisições para rotas
sensíveis, você precisa exigir intenção real do usuário.

  • Não exigir CSRF token em rotas que mudam estado (criar, atualizar, deletar, transferir).
  • Permitir CORS permissivo demais sem entender pré-voos e contexto de cookies.
  • Usar cookies sem flags corretas (HttpOnly, Secure, SameSite) e confiar em “boas práticas”.
  • Endpoints “GET” com efeitos colaterais: requisitar algo via GET não deve alterar estado.
  • Não validar método e headers: aceitar POST/PUT sem validações mínimas pode abrir caminhos.
Exemplo (conceito) de proteção CSRF no backend
Token duplo (cookie + header)

// Pseudocódigo de middleware (ajuste para sua stack)
function csrfMiddleware(req, res, next) {
  const method = req.method.toUpperCase();
  const isStateChanging = ["POST","PUT","PATCH","DELETE"].includes(method);

  if (!isStateChanging) return next();

  const csrfCookie = req.cookies["CSRF-TOKEN"];
  const csrfHeader = req.headers["x-csrf-token"];

  if (!csrfCookie || !csrfHeader) {
    return res.status(403).json({ error: "CSRF token ausente" });
  }

  // Use comparação segura, e gere novo token após login se aplicável
  if (csrfCookie !== csrfHeader) {
    return res.status(403).json({ error: "CSRF token inválido" });
  }

  next();
}

// Front (conceito): ler o cookie CSRF-TOKEN e mandar no header
// fetch("/endpoint", { method: "POST", headers: { "x-csrf-token": token }, credentials: "include" })

Regra de ouro: rotas que alteram estado precisam exigir prova de intenção do usuário.
“Basta estar logado” não é intenção.

4Exposição de dados e falhas de tratamento de erros (A02/2021 — Cryptographic Failures e Logging)

Segurança também é o que você faz quando algo dá errado. Mensagens detalhadas, logs com segredos e dados
sensíveis em respostas viram caminho direto para exploração e impacto.

  • Erros retornando stack trace ou detalhes internos para o cliente.
  • Logs com dados sensíveis (tokens, senhas, chaves, PII) sem mascaramento.
  • Criptografia inexistente ou fraca (especialmente em trânsito e armazenamento).
  • Falta de validação de criptografia/assinatura (ex.: confiar em payload assinado sem checar contexto).
  • Ambientes misturados: usar credenciais de produção em dev/test e vice-versa.

Regra prática: padronize mensagens de erro (genéricas para o cliente) e segregue logs
(detalhados apenas em sistemas internos, com redaction/mascaramento).

Quer elevar seu nível em segurança sem perder velocidade?

Eu recomendo que você leia os próximos posts do yurideveloper.com para transformar OWASP em práticas no dia a dia:
threat modeling, validação robusta, controle de acesso e hardening de sessão.

Fechei esse guia com foco em erros que aparecem em revisões e testes reais. Se você quiser, me diga sua stack (backend e front)
que eu adapto o checklist para o seu cenário.



“`