Reading an HTTP exchange like an attacker

5 min read

An HTTP message is a request line, headers, a blank line, then an optional body. The interesting security state almost always rides in the headers or the body, not the URL — which is exactly why you have to look past the address bar.

POST /api/login HTTP/1.1        <- method + path + version
Host: shop.example                <- which vhost
Cookie: session=eyJ1Ijoi...       <- state the browser carries back every time
Content-Type: application/json
                                  <- blank line ends the headers
{"user":"guest","pass":"..."}     <- body

Three habits find most bugs:

• Decode everything that looks encoded. A cookie or token that is base64 is not encrypted — it is a sticky note in a font you have to squint at. Decode it and read what the app believes about you.
• Change one thing and resend. An id, a role, a boolean, a host header. The server's reaction tells you whether it re-checked.
• Read the response you were not supposed to notice. Error bodies, extra headers, redirects with data in them. Apps leak in the parts the page never renders.

Every lab in this track is solvable with exactly these three habits and no tools beyond a base64 decoder.