Por que segurança não é feature opcional

Um padrão comum em projeto real: o time entrega o cadastro, o login, a tela de pedidos — tudo funcionando — e deixa "revisar segurança" pra uma sprint futura que nunca chega, ou chega tarde demais, depois que alguém de fora já encontrou o problema. A ideia por trás dessa trilha é simples: segurança não é uma tela, um botão ou uma biblioteca que se adiciona depois. É uma característica de como cada decisão já foi tomada — como uma senha é guardada, como uma sessão é validada, como um dado de outro usuário é ou não exposto.

Por que "adicionar depois" quase sempre falha

Pega um exemplo concreto: um endpoint GET /pedidos/:id foi escrito checando só "existe usuário logado?" — não "esse pedido pertence a esse usuário?". Isso funciona perfeitamente nos testes manuais do time, porque quem testa só olha os próprios pedidos. O problema só aparece quando alguém troca o número na URL de propósito. Corrigir isso depois não é "adicionar uma feature" — é encontrar, em todo lugar do sistema que carrega um recurso por id, se essa checagem de dono existe. Quanto mais tarde isso é notado, mais lugares existem pra revisar, e mais tempo o problema já esteve exposto em produção.

O mesmo vale pra decisões que parecem só "detalhe de implementação": guardar senha com hash em vez de texto puro, marcar um cookie de sessão como HttpOnly, escapar um texto antes de renderizar na tela. Nenhuma dessas coisas é visível pra quem usa o produto no dia a dia — só fica visível quando alguém tenta explorar a ausência delas.

Por onde um ataque entra numa requisição comum

Não existe "o lugar onde a segurança mora" num sistema — existe uma cadeia inteira, e cada elo dela é explorado de um jeito diferente. O diagrama abaixo segue uma requisição simples (usuário buscando o próprio pedido) e marca, em cada trecho do caminho, que tipo de problema mora ali — cada um vira uma lição adiante nesta trilha.

Repare que "autenticação" (as próximas quatro lições) resolve só o primeiro pedaço dessa história: provar quem está falando com o servidor. Todo o resto do diagrama continua existindo mesmo com autenticação perfeita — um usuário autenticado de verdade ainda pode tentar acessar o pedido de outra pessoa, ainda pode injetar um script num campo de comentário, ainda pode estar numa rede comprometida.

Defesa em profundidade: nenhuma camada sozinha basta

Um erro comum é escolher uma defesa e tratá-la como suficiente — "usamos HTTPS, então estamos seguros" (HTTPS não impede XSS nem SQL injection), ou "validamos no frontend, então está protegido" (qualquer um consegue chamar a API direto, pulando o frontend inteiro). A prática que realmente funciona se chama defesa em profundidade: várias camadas independentes, de modo que a falha de uma sozinha não derruba o sistema inteiro. Um cookie HttpOnly (lição 3) não impede XSS — mas reduz o estrago de um XSS que já aconteceu, porque o script injetado não consegue ler o cookie de sessão mesmo assim.

O que esta trilha cobre

As primeiras lições respondem a pergunta que dá nome ao resumo desta trilha: como autenticação funciona de verdade — sessão com cookie, bearer token, JWT — não só os nomes, mas o mecanismo por trás de cada um. Depois disso, a trilha segue pelos ataques mais comuns contra aplicação web:

• Hashing de senha — por que "criptografar a senha" é a frase errada
• XSS e CSRF — quando o navegador de outra pessoa é usado contra ela mesma
• SQL injection e IDOR — quando input vira comando, ou autenticação existe mas autorização não
• Força bruta, política de senha e cabeçalhos HTTP de proteção
• MITM e OAuth — por que HTTPS importa, e como funciona o "Entrar com Google"

A última lição junta boa parte disso num único exercício: pegar uma API cheia de falhas e corrigi-las uma a uma.