Web apps, protected end to end.

HTTP e HTTPS: a baseHTTP and HTTPS: the base

Esta nota é o lado de dentro da muralha: como proteger a aplicação web que você constrói, não como atacar a de outra pessoa (isso fica na nota de Red Team). O fio condutor é simples: HTTP é um protocolo de texto, sem memória entre uma requisição e a próxima; tudo que chamamos de "segurança de app web" é uma camada de proteções em cima dessa base simples — cifrar o transporte, autenticar quem está do outro lado, lembrar quem é quem entre requisições, e desconfiar de qualquer dado que entra.This note is the inside of the wall: how to protect the web app you build, not how to attack someone else's (that is the Red Team note). The thread running through it is simple: HTTP is a text protocol with no memory between one request and the next; everything we call "web app security" is a layer of protections on top of that simple base — encrypting the transport, authenticating who is on the other side, remembering who is who between requests, and distrusting any data that comes in.

HTTP e HTTPS: a mesma coisa, uma delas cifradaHTTP and HTTPS: the same thing, one of them encrypted

HTTP descreve o que é trocado (método, cabeçalhos, corpo); HTTPS é HTTP rodando dentro de uma conexão TLS, que cifra e autentica o transporte. A nota de segurança e redes já mostrou isso na prática: uma captura de pacotes da porta 80 mostra a requisição em texto puro; da porta 443, só ruído. TLS resolve três problemas de uma vez:HTTP describes what is exchanged (method, headers, body); HTTPS is HTTP running inside a TLS connection, which encrypts and authenticates the transport. The security and networking note already showed this in practice: a packet capture of port 80 shows the request in plain text; of port 443, just noise. TLS solves three problems at once:

Cabeçalhos de segurançaSecurity headers

O navegador obedece a instruções que o SERVIDOR manda em cabeçalhos HTTP de resposta. Um punhado deles fecha a maior parte das portas de ataque mais comuns, de graça, sem mudar uma linha de lógica de negócio.The browser obeys instructions the SERVER sends in HTTP response headers. A handful of them close most of the common attack doors, for free, without changing a line of business logic.

CORS: a exceção controlada à regra de mesma origemCORS: the controlled exception to same-origin

Por padrão, o navegador bloqueia JavaScript de um site lendo a resposta de outro (a same-origin policy). Access-Control-Allow-Origin e companhia são o jeito do SERVIDOR abrir uma exceção explícita para origens específicas. Access-Control-Allow-Origin: * é seguro para uma API pública e sem cookies; para uma API autenticada, liste as origens exatas e use Access-Control-Allow-Credentials: true só quando precisar enviar cookies entre origens.By default, the browser blocks JavaScript from one site reading another site's response (the same-origin policy). Access-Control-Allow-Origin and friends are how the SERVER opens an explicit exception for specific origins. Access-Control-Allow-Origin: * is fine for a public, cookie-free API; for an authenticated API, list exact origins and use Access-Control-Allow-Credentials: true only when you need to send cookies cross-origin.

Exercício: ver e testar os cabeçalhos de um appExercise: see and test an app's headers

mkdir lab-headers && cd lab-headers
cat > server.js <<'EOF'
const http = require('http');
http.createServer((req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/html',
    'Strict-Transport-Security': 'max-age=63072000; includeSubDomains',
    'Content-Security-Policy': "default-src 'self'; script-src 'self'",
    'X-Content-Type-Options': 'nosniff',
    'X-Frame-Options': 'DENY',
    'Referrer-Policy': 'strict-origin-when-cross-origin',
    'Permissions-Policy': 'camera=(), microphone=(), geolocation=()',
  });
  res.end('<h1>ola</h1>');
}).listen(3000);
EOF
cat > Dockerfile <<'EOF'
FROM node:22-slim
COPY server.js .
CMD ["node", "server.js"]
EOF
docker build -t lab-headers . && docker run -d -p 127.0.0.1:3000:3000 lab-headers
curl -sI http://localhost:3000 | grep -iE "strict-transport|content-security|x-content-type|x-frame|referrer|permissions"

Resultado esperado: o curl -I (só cabeçalhos) mostra todas as seis linhas configuradas no servidor. Compare depois com um site real: abra o DevTools do navegador → aba Network → clique na primeira requisição → "Headers", ou rode o mesmo curl -sI contra https://baselarte.com.Expected result: curl -I (headers only) shows all six lines configured on the server. Afterwards compare with a real site: open the browser DevTools → Network tab → click the first request → "Headers", or run the same curl -sI against https://baselarte.com.

Cookies: os três atributos que importamCookies: the three attributes that matter

Um cookie é um pedacinho de texto que o servidor pede ao navegador para guardar e devolver em toda requisição futura ao mesmo site. É o mecanismo mais comum para "lembrar" quem está logado — e, mal configurado, uma das formas mais fáceis de vazar uma sessão inteira.A cookie is a small piece of text the server asks the browser to store and send back on every future request to the same site. It is the most common mechanism to "remember" who is logged in — and, misconfigured, one of the easiest ways to leak a whole session.

Fixação de sessãoSession fixation

Um ataque simples: o atacante planta um ID de sessão conhecido na vítima (por um link, ou porque o site aceita qualquer ID enviado) e espera ela fazer login — se o site mantém o MESMO ID depois do login, o atacante agora está "logado" também. A defesa: sempre gerar um ID de sessão novo no momento do login (e de novo em qualquer mudança de privilégio), nunca aceitar um ID de sessão que já veio do cliente antes de autenticar.A simple attack: the attacker plants a known session ID on the victim (via a link, or because the site accepts any submitted ID) and waits for them to log in — if the site keeps the SAME ID after login, the attacker is now "logged in" too. The defence: always generate a new session ID at the moment of login (and again on any privilege change), never accept a session ID that arrived from the client before authenticating.

Autenticação stateful: sessões no servidorStateful authentication: server-side sessions

Autenticação stateful (com estado): o servidor guarda, num banco ou cache (Redis é o padrão de mercado), um registro de cada sessão ativa. O cookie carrega só um ID opaco e aleatório — o resto da informação (quem é o usuário, quando expira) fica no servidor.Stateful authentication: the server keeps, in a database or cache (Redis is the market standard), a record of each active session. The cookie carries only an opaque, random ID — the rest of the information (who the user is, when it expires) lives on the server.

Logout, na práticaLogout, in practice

# pseudocódigo do lado do servidor
POST /login    -> gera sid aleatório, grava {user_id, criado_em} no Redis, seta cookie Secure+HttpOnly+SameSite=Lax
GET  /perfil   -> lê sid do cookie, busca no Redis, 401 se não achar ou expirado
POST /logout   -> apaga a chave sid no Redis, expira o cookie no navegador

Esse é o ponto central: logout stateful é só DELETE. Isso fica bem mais difícil no modelo stateless, que vem a seguir.This is the key point: stateful logout is just a DELETE. This gets much harder in the stateless model, which comes next.

Autenticação stateless: JWT, access e refreshStateless authentication: JWT, access and refresh

Autenticação stateless (sem estado): em vez de um ID opaco, o servidor assina um token que carrega os dados nele mesmo — tipicamente um JWT (JSON Web Token). Qualquer servidor que conheça a chave de assinatura pode validar o token sozinho, sem consultar banco nenhum. É o modelo padrão para APIs e microsserviços, e para SPAs que falam com uma API separada.Stateless authentication: instead of an opaque ID, the server signs a token that carries the data inside itself — typically a JWT (JSON Web Token). Any server that knows the signing key can validate the token on its own, with no database lookup. It is the standard model for APIs and microservices, and for SPAs talking to a separate API.

A anatomia de um JWTThe anatomy of a JWT

Access token curto + refresh token longoShort access token + long refresh token

O padrão que resolve o maior problema do modelo stateless (não dá para "apagar" um token já emitido) é usar DOIS tokens com vidas diferentes:The pattern that solves stateless's biggest problem (you cannot "delete" an already-issued token) is using TWO tokens with different lifetimes:

Padrão recomendado hoje: access token em memória, refresh token num cookie HttpOnly+Secure+SameSite=Strict. Evite localStorage para qualquer um dos dois se puder.Today's recommended pattern: access token in memory, refresh token in an HttpOnly+Secure+SameSite=Strict cookie. Avoid localStorage for either one if you can.

Rotação de refresh token e detecção de reusoRefresh token rotation and reuse detection

A cada uso, o refresh token é TROCADO por um novo, e o antigo é invalidado. Se o antigo aparecer de novo (alguém tentando reusar um token roubado, ou uma cópia antiga), isso significa que ele vazou — a resposta correta é revogar a CADEIA inteira daquele token, derrubando a sessão.On every use, the refresh token is SWAPPED for a new one, and the old one is invalidated. If the old one shows up again (someone trying to reuse a stolen token, or an old copy), that means it leaked — the correct response is to revoke the WHOLE chain for that token, killing the session.

# pseudocódigo do endpoint de refresh
POST /refresh  (cookie: refresh_token=rt_antigo)
  1. valida assinatura e expiração de rt_antigo
  2. rt_antigo já foi usado antes (está na lista de "já trocados")?
       SIM -> REUSO DETECTADO: revoga toda a família de tokens desse usuário, força novo login
       NÃO -> gera access_token novo (minutos) + refresh_token novo (dias)
              marca rt_antigo como "já trocado", responde com os dois

Qual escolherWhich one to choose

Nenhum dos dois é "o certo"; são otimizados para coisas diferentes.Neither one is "the right one"; they are optimised for different things.

CSRF: o pedido que você não pediuCSRF: the request you did not ask for

Cross-Site Request Forgery: um site malicioso faz o SEU navegador mandar uma requisição para um site onde você já está logado, usando seus cookies automaticamente — sem roubar nada, só abusando do fato de que o navegador sempre anexa os cookies do domínio.Cross-Site Request Forgery: a malicious site makes YOUR browser send a request to a site where you are already logged in, using your cookies automatically — without stealing anything, just abusing the fact that the browser always attaches the domain's cookies.

SQL injection e XSS: o lado de quem constróiSQL injection and XSS: the builder's side

Confiar em qualquer dado que entra de fora é a raiz da maioria das falhas de aplicação web. As duas mais comuns já apareceram na nota de Red Team do ponto de vista de quem ataca; aqui é o lado de quem constrói.Trusting any data that comes in from outside is the root of most web application flaws. The two most common ones already showed up in the Red Team note from the attacker's side; here is the builder's side.

SQL injection: nunca monte SQL colando textoSQL injection: never build SQL by pasting text

-- NUNCA: concatena a entrada direto na consulta
const query = `SELECT * FROM usuarios WHERE email = '${emailDoFormulario}'`;

-- SEMPRE: consulta parametrizada — a entrada é um VALOR, nunca parte do comando
SELECT * FROM usuarios WHERE email = $1;   -- Postgres (driver node-postgres, por exemplo)

Veja a nota de Postgres para os comandos e a seção de exploração da nota de Red Team para como essa falha é usada do outro lado. ORMs (Prisma, SQLAlchemy, ActiveRecord) fazem isso por padrão — o risco real aparece quando alguém usa SQL "cru" dentro do ORM para um caso especial e esquece de parametrizar.See the Postgres note for commands and the Red Team note's exploitation section for how this flaw is used from the other side. ORMs (Prisma, SQLAlchemy, ActiveRecord) do this by default — the real risk shows up when someone drops down to "raw" SQL inside the ORM for a special case and forgets to parameterise.

XSS: escapar saída, não só validar entradaXSS: escape output, not just validate input

Frameworks modernos (React, Vue, Angular) escapam a saída por padrão quando você usa a sintaxe normal de template — o perigo mora nas "válvulas de escape" que pulam essa proteção de propósito.Modern frameworks (React, Vue, Angular) escape output by default when you use their normal template syntax — the danger lives in the "escape hatches" that skip that protection on purpose.

// React: ESCAPADO automaticamente, seguro mesmo se bio vier de um usuário
<p>{usuario.bio}</p>

// React: a válvula de escape — NUNCA com texto de usuário sem sanitizar antes
<div dangerouslySetInnerHTML={{ __html: usuario.bio }} />

Se você realmente precisa renderizar HTML vindo do usuário (um editor rich-text, por exemplo), sanitize com uma biblioteca testada para isso (como DOMPurify) — nunca confie em regex caseira para "limpar" HTML.If you genuinely need to render user-supplied HTML (a rich-text editor, for example), sanitise it with a battle-tested library (like DOMPurify) — never trust a homemade regex to "clean" HTML.

Uma checklist curtaA short checklist

• Toda consulta com dado externo é parametrizada; nenhum SQL é montado por concatenação de string.Every query with external data is parameterised; no SQL is built by string concatenation.
• Toda saída em HTML usa a escapagem padrão do framework; dangerouslySetInnerHTML/v-html/|safe só com conteúdo sanitizado.All HTML output uses the framework's default escaping; dangerouslySetInnerHTML/v-html/|safe only with sanitised content.
• Validação de entrada acontece no SERVIDOR, mesmo que também exista no navegador (o navegador é só conforto para o usuário, não é segurança).Input validation happens on the SERVER, even if it also exists in the browser (the browser is just user convenience, not security).
• Um WAF e um Content-Security-Policy são camadas extras, nunca a única defesa.A WAF and a Content-Security-Policy are extra layers, never the only defence.

A nova fronteira: segurança de agentes de IAThe new frontier: AI agent security

Tudo até aqui assume que quem fala com a sua aplicação é um navegador controlado por uma pessoa. A nova peça é um agente de IA: um modelo de linguagem que lê conteúdo, decide, e age — chama APIs, roda código, lê e-mails, usa ferramentas via protocolos como o MCP (Model Context Protocol). Isso muda o modelo de ameaça: o "usuário" que manda instruções pode agora ser um texto que o próprio agente leu em algum lugar.Everything so far assumes whoever talks to your application is a browser controlled by a person. The new piece is an AI agent: a language model that reads content, decides, and acts — calls APIs, runs code, reads emails, uses tools through protocols like MCP (Model Context Protocol). This changes the threat model: the "user" issuing instructions can now be a piece of text the agent itself read somewhere.

O OWASP Top 10 para aplicações LLM (2025)The OWASP Top 10 for LLM Applications (2025)

Prompt injection, de pertoPrompt injection, up close

É o risco #1 da lista, e o mais diferente de tudo que veio antes nesta nota: não existe "escapar a entrada" que resolva, porque a instrução maliciosa e o conteúdo legítimo chegam pelo MESMO canal — texto em linguagem natural. Dois sabores:It is risk #1 on the list, and the one most unlike everything else in this note: there is no "escape the input" fix, because the malicious instruction and the legitimate content arrive through the SAME channel — natural-language text. Two flavours:

Agência excessiva e os riscos específicos do MCPExcessive agency and MCP-specific risks

Quando o agente só conversa, o pior caso é uma resposta errada. Quando ele tem ferramentas — manda e-mail, acessa um banco, roda código, chama uma API de pagamento — o pior caso é uma AÇÃO errada. O MCP (o protocolo mais comum hoje para conectar agentes a ferramentas) trouxe à tona uma família nova de riscos em 2025:When the agent only talks, the worst case is a wrong answer. When it has tools — sends email, accesses a database, runs code, calls a payment API — the worst case is a wrong ACTION. MCP (today's most common protocol for connecting agents to tools) surfaced a new family of risks in 2025:

Defesas que funcionam hojeDefences that work today

O paralelo com o resto desta nota: um agente com uma ferramenta de banco de dados sem privilégio mínimo é o mesmo erro que uma aplicação conectando como super-usuário do Postgres (nota de Postgres); confiar cegamente no texto que um agente leu é o mesmo erro de confiar na entrada de um usuário sem validar (seção de SQL injection e XSS acima). O princípio não muda; a superfície de ataque é que é nova.The parallel with the rest of this note: an agent with a database tool and no least privilege is the same mistake as an application connecting as a Postgres superuser (the Postgres note); blindly trusting text an agent read is the same mistake as trusting user input without validation (the SQL injection and XSS section above). The principle does not change; it is the attack surface that is new.

Cola e revisãoCheat sheet and review

ColaCheat sheet

Perguntas de revisãoReview questions