Segurança web não começa procurando uma falha. Começa entendendo o que acontece quando alguém abre uma página, envia um formulário ou acessa uma área autenticada. Uma aplicação é formada por pessoas, navegador, rede, servidor, dados e regras de acesso. Cada transição entre essas partes é uma decisão de segurança.
Este roteiro mostra como enxergar essas transições — e por que essa forma de olhar encontra mais problemas que decorar nomes de vulnerabilidades.
Comece pelo caminho de uma requisição
Quando o navegador faz uma requisição HTTP, ele envia um método, um endereço, cabeçalhos e, às vezes, um corpo com dados. O servidor decide como tratar aquilo e devolve uma resposta.
Uma requisição real se parece com isto:
POST /api/pedidos/1042/cancelar HTTP/1.1
Host: loja.exemplo.com
Cookie: sessao=a1b2c3d4...
Content-Type: application/json
{"motivo": "desistencia"}Para estudar com método, faça quatro perguntas sobre ela:
- Quem pode enviar esta requisição?
- Quais dados entram nela e como são validados?
- Que autorização é necessária para executar a ação?
- O que aparece na resposta, nos logs e no navegador?
Aplicando à requisição acima: o cookie diz quem está autenticado, mas nada nela garante que essa pessoa seja dona do pedido 1042. Se o servidor cancelar o pedido apenas por ter recebido uma sessão válida, trocar o número para 1043 cancela o pedido de outra pessoa.
Esse é o raciocínio inteiro da categoria mais frequente do OWASP Top 10 — e você chegou nele sem decorar nenhum nome, só perguntando quem pode fazer o quê.
Autenticação não é autorização
Autenticação responde “quem está tentando entrar?”. Autorização responde “o que essa identidade pode fazer?”.
A confusão entre as duas é a origem de boa parte dos problemas de acesso. Uma pessoa pode estar perfeitamente autenticada e ainda assim não ter permissão para ver dados de outro usuário, alterar uma configuração ou executar uma ação administrativa.
Ao revisar uma funcionalidade, procure a verificação de autorização perto da ação sensível, no servidor. Dois sinais de alerta:
- a permissão é verificada só na montagem da tela, não na execução da ação;
- a decisão usa um identificador que veio do cliente sem ser reconferido.
Botões invisíveis não substituem uma regra no servidor. A interface esconde a opção; a requisição continua podendo ser enviada à mão.
Entenda o papel da sessão
Depois do login, a aplicação precisa reconhecer a pessoa nas próximas requisições. Isso costuma acontecer por meio de um identificador de sessão ou token. Esse identificador é a sessão autenticada: quem o possui, age como aquela pessoa.
Para quem desenvolve, o mínimo:
| Proteção | O que evita |
|---|---|
| HTTPS em todo o tráfego | Captura do identificador em trânsito |
Cookie com HttpOnly | Leitura por código JavaScript na página |
Cookie com Secure | Envio em conexão não cifrada |
Cookie com SameSite | Envio automático a partir de outro site |
| Novo identificador após o login | Fixação de sessão |
| Expiração e encerramento explícito | Sessão válida indefinidamente |
| Nova autenticação em ações críticas | Uso de sessão esquecida aberta |
Trocar o identificador logo após o login merece destaque: sem isso, um identificador que o atacante tenha conseguido plantar antes continua válido depois que a vítima se autentica.
Para quem estuda, observe como a aplicação mantém estado em um ambiente de treinamento — sem reutilizar técnicas em sistemas de terceiros.
Use o OWASP Top 10 como mapa, não como checklist cego
O OWASP Top 10 reúne riscos recorrentes para aplicações web e é um ótimo índice de estudo. A edição atual é a de 2025:
| Categoria | |
|---|---|
| A01 | Broken Access Control |
| A02 | Security Misconfiguration |
| A03 | Software Supply Chain Failures |
| A04 | Cryptographic Failures |
| A05 | Injection |
| A06 | Insecure Design |
| A07 | Authentication Failures |
| A08 | Software or Data Integrity Failures |
| A09 | Security Logging and Alerting Failures |
| A10 | Mishandling of Exceptional Conditions |
Duas observações úteis para quem está começando. A primeira: falha de controle de acesso lidera a lista — é a categoria que a pergunta “quem pode enviar esta requisição?” encontra. A segunda: a lista não é um ranking de gravidade para o seu caso. A mesma categoria tem impacto muito diferente dependendo do dado, da arquitetura e dos controles existentes.
Escolha um tópico por vez. Entenda qual propriedade de segurança ele afeta, qual decisão de desenvolvimento o reduz e como uma equipe confirmaria a correção. O objetivo é aprender a construir e revisar sistemas melhores, não apenas reconhecer nomes de vulnerabilidades.
Faça perguntas de arquitetura antes de testar
Desenhe o caminho de uma funcionalidade: navegador, rota, serviço, banco de dados e resposta. Em cada transição, pergunte quais dados são confiáveis, qual identidade está agindo, que autorização é verificada e que evidência fica registrada.
A regra que organiza tudo isso: dado que atravessou a fronteira do cliente não é confiável, por mais que a interface tenha validado. A validação no navegador existe para a experiência da pessoa; a validação no servidor existe para a segurança. Elas parecem redundantes e não são — só a segunda é obrigatória.
Vale notar o que entrou na lista de 2025: falhas de cadeia de suprimento de software agora ocupam a terceira posição. Para quem desenvolve, isso significa que a dependência que você instalou faz parte da sua superfície de ataque. Saber o que o projeto usa, de onde vem e com que frequência é atualizado deixou de ser tarefa secundária.
Para quem desenvolve, segurança também aparece no ciclo de mudança: revisão de código, testes, atualização de dependências, logs úteis e uma forma de corrigir rapidamente. Para quem estuda, o foco é entender os controles e validar hipóteses em aplicações educacionais ou próprias.
Próximo passo seguro
Monte um laboratório local com uma aplicação educacional deliberadamente vulnerável — OWASP WebGoat e Juice Shop existem exatamente para isso. Antes de começar, documente o objetivo, isole a rede e registre o que espera observar.
Um primeiro exercício concreto: abra as ferramentas de desenvolvedor do navegador, use uma funcionalidade qualquer da aplicação de treino e observe a requisição que ela gera. Depois responda às quatro perguntas da primeira seção sobre ela. É o exercício mais barato que existe e ensina mais que qualquer lista de comandos.
Depois, compare esse roteiro com o artigo sobre laboratório seguro e avance para autenticação e proteção de contas.
Estude apenas em aplicações próprias, educacionais ou com autorização explícita. Encontrar um problema em um sistema de terceiros não autoriza testá-lo: use o canal de divulgação responsável da organização.
