0.3 — Anatomia de uma requisição HTTP (o coração de tudo)

Toda interação na web é um par requisição → resposta. Se você entender as partes, entende 80% do curso. Vamos dissecar.

A REQUISIÇÃO (o que o cliente manda)

POST /api/leads HTTP/1.1                 ← (1) linha inicial: MÉTODO + CAMINHO + versão
Host: feed-monetizacao.exemplo.dev        ← (2) cabeçalhos (headers): metadados
Content-Type: application/json
Authorization: Bearer eyJhbGci...
Cookie: cms_token=eyJhbGci...
                                          ← (linha em branco separa cabeçalho do corpo)
{"name":"João","whatsapp":"5511999998888"} ← (3) corpo (body): os dados enviados

(1) Método — o verbo, diz a intenção:

Método	Intenção	Analogia	Muda dados?
GET	ler algo	"me mostra o cardápio"	Não
POST	criar algo	"quero fazer um pedido novo"	Sim
PUT / PATCH	alterar algo existente	"muda meu pedido"	Sim
DELETE	apagar algo	"cancela meu pedido"	Sim (destrutivo!)

É por isso que o semáforo de segurança do seu tutorial funciona: GET é 🟢 verde (só lê), POST é 🟡 amarelo (cria), DELETE é 🔴 vermelho (destrói). O método já diz o risco.

(1) Caminho (path) — onde: /api/leads é o "endereço" dentro do site. Cada caminho é um endpoint (um ponto de entrada da aplicação). O conjunto de todos os endpoints é a superfície de ataque — quanto mais portas, mais lugares para testar.

(2) Cabeçalhos (headers) — metadados do pedido: quem você diz ser, que formato manda, que idioma prefere. Dois são cruciais para segurança:

Authorization: Bearer <token> — sua "credencial" (veja 0.7).
Cookie: ... — dado que o navegador guarda e reenvia automaticamente (veja 0.6).

(3) Corpo (body) — os dados de fato, normalmente em JSON (veja 0.8). Só POST/PUT/PATCH costumam ter corpo.

A RESPOSTA (o que o servidor devolve)

HTTP/1.1 201 Created                      ← (1) código de status
Content-Type: application/json            ← (2) cabeçalhos da resposta
Set-Cookie: cms_token=...; HttpOnly       
                                          
{"success":true,"id":"abc-123"}           ← (3) corpo da resposta

(1) Código de status — um número de 3 dígitos que resume o que aconteceu. Você precisa decorar estas famílias:

Faixa	Significa	Exemplos que importam
2xx	Deu certo	`200 OK` (leu), `201 Created` (criou)
3xx	Redirecionamento	`301/302` (vá para outro lugar), `307`
4xx	Você errou / foi barrado	`400` (pedido inválido), `401` (sem login), `403` (proibido), `404` (não existe), `405` (método errado), `429` (rate limit — bom!)
5xx	O servidor errou	`500` (erro interno — às vezes é o achado!), `502/503` (caiu)

A leitura de segurança do status é contextual. Um 200 no feed público é ótimo. Um 200 num endpoint de admin que deveria pedir login é um achado crítico — o sistema deixou você entrar sem credencial. Mesmo número, significados opostos. É por isso que "qualquer 200 em endpoint protegido = achado" (do seu Ex. 2).

(2) Cabeçalhos da resposta — aqui moram várias defesas (CSP, HSTS, X-Frame-Options) e vários vazamentos (x-powered-by: Next.js conta ao atacante qual tecnologia você usa → ele busca falhas dessa tecnologia). Você vai aprender a ler isso no Ex. 1.

(3) Corpo da resposta — o conteúdo: a página HTML, ou o JSON com os dados.

🎯 Fixe: requisição = método + caminho + cabeçalhos + corpo. Resposta = status + cabeçalhos + corpo. Toda ferramenta (curl, Burp, navegador) só manipula essas 8 coisas. Domine-as e nada mais te assusta.