Post cover image

August 9, 2026

The Protocol Every Hacker Should Learn Before Touching Burp Suite

Type http://example.com into a browser and hit Enter. A page shows up — text, maybe an image or a login box — and you move on. You don't…

By Zer0trace

10 min read

Type http://example.com into a browser and hit Enter. A page shows up — text, maybe an image or a login box — and you move on. You don't think about it again.

That's what good engineering is supposed to do: disappear.

But in that split second, a small storm happened. Your browser figured out where "example.com" actually lives. It opened a connection to a machine it had never talked to before. It wrote out a request describing exactly what it wanted, sent it off, and waited. The server read that request, decided how to respond, and sent something back.

You saw a webpage. A security engineer sees a conversation — one they can read every word of.

That shift is really the moment someone stops thinking like a user and starts thinking like a security professional. Once you can see the conversation, you can ask the more interesting question: what happens if I say something the server doesn't expect?

That question is where almost every web vulnerability starts.

Why bother with HTTP before anything else

If you've spent any time around cybersecurity content, you've probably seen people jump straight to SQL injection payloads or a screen recording of Burp Suite doing something impressive. It's tempting to skip the "boring" fundamentals and go straight for the fireworks.

The problem is that none of it actually makes sense without HTTP.

Burp Suite isn't magic — it's a proxy. It sits between your browser and the target server, shows you the raw traffic going both directions, and lets you edit it before it's sent. Repeater resends a request with your tweaks. Intruder automates sending a lot of variations. Every feature assumes you already know what a request and response are. If you don't, Burp just looks like a wall of text.

Same story with PortSwigger's Web Security Academy, probably the best free resource out there for learning this stuff. Nearly every lab — SQLi, broken access control, CSRF, SSRF, request smuggling — is really a lab about HTTP being trusted somewhere it shouldn't be. The vulnerability isn't some separate thing bolted onto the web. It is HTTP, misused.

So before we get to breaking anything, let's look at how it's supposed to work.

What HTTP actually is

HTTP — HyperText Transfer Protocol — is just an agreed-upon way for two programs, usually a browser and a server, to ask for things and hand things back.

Before it existed, there was no standard way for one program to say "give me this document" and get something predictable in return. Tim Berners-Lee, working at CERN around 1989–1991, needed researchers to be able to link and pull documents across completely different machines and operating systems. HTTP was the fix: a plain-text protocol simple enough that you could, in theory, type it by hand into a raw socket and get a sensible reply back.

A few ideas do most of the work here:

It's client-server. One side asks, the other answers. The client always starts the conversation — a plain HTTP server doesn't just push things at you out of nowhere.

It's request-response. Every exchange is a pair: one request, one response.

And it's stateless, which is the part that trips people up. HTTP has no memory of its own. Each request lands as a completely fresh event — the server doesn't inherently know that the request you just sent came from "the same person" who logged in thirty seconds ago. That's why cookies and sessions exist: they're a workaround bolted onto a protocol that was never built to remember you. It's also why an entire category of bugs — session fixation, broken authentication, weak cookies — exists in the first place.

Picture ordering at a counter where the cashier forgets you the instant you stop talking. You have to restate your order, your name, everything, every single time. That's HTTP without cookies.

A short history, because it explains a lot

HTTP didn't show up fully formed — it grew because the web kept outgrowing it.

HTTP/0.9 (1991) was bare bones: one method (GET), no headers, no status codes. You asked for a document, got a document, connection closed.

HTTP/1.0 (1996) added headers, status codes, and support for more than plain HTML. The catch — every request still opened a brand-new connection. A page with ten images meant ten separate handshakes.

HTTP/1.1 (1997) fixed that with persistent connections, so requests could share a connection. It also made the Host header mandatory, which is why one server can host multiple websites on a single IP — and it's the root of a whole class of bugs called Host header injection. HTTP/1.1 is still everywhere today.

HTTP/2 (2015) went after a different bottleneck: even with persistent connections, requests were still processed one at a time, so a slow one blocked everything behind it. HTTP/2 added multiplexing — many requests interleaved over one connection — plus header compression. It's binary now instead of plain text, which is faster but harder to read by eye.

HTTP/3 (2022) changed the transport layer entirely, moving from TCP to QUIC over UDP. That mostly kills head-of-line blocking and speeds up connection setup, which matters a lot on shaky mobile networks.

None

The pattern across all five versions: each one exists because the last one hit a wall at scale. Nothing changed just for the sake of it.

Why we need a protocol at all

Imagine HTTP didn't exist. Your browser wants a page from some server. Without an agreed format, how would it even phrase the request? Would every site invent its own dialect, forcing every browser to support a hundred incompatible ones?

That's the value of a protocol — it's a shared contract. Both sides agree in advance on the shape of the conversation, so a browser built by one company talks perfectly well to a server built by a completely different one, in a different language, on different hardware, without either side knowing anything about the other's internals.

Worth being precise here: a protocol is the rulebook. An application — a browser, or a web server like Nginx — is a program that implements that rulebook. HTTP is the rulebook; Chrome, Firefox, Apache, and Nginx are all applications that speak it, each in their own way.

What happens when you type a URL

Say you type http://abc.com and hit Enter. Here's the chain that fires before you see anything:

The browser first checks if it already has abc.com's IP address cached from a recent lookup. If it does, it skips straight to connecting. If not, it checks your OS's hosts file — a local file that can manually map domain names to IP addresses (this is exactly why pentesters and developers use it to point a domain at a test server). Still nothing? It asks a DNS resolver, often your ISP's or a public one like 1.1.1.1, to translate the name into an address. That resolver may not know either, so it asks around — root servers, then .com servers, then the domain's own authoritative server — until it gets a real answer.

Eventually, abc.com resolves to something like 193.100.100.10.

Why does this matter for security work? Because browsers don't actually understand domain names. Networking hardware moves packets by IP address, full stop. The domain name is a convenience for humans — the IP is the real destination.

How the connection actually gets made

Once the browser has an IP, it doesn't just start firing data at it. It needs a reliable connection first — TCP's three-way handshake:

  1. SYN — the browser: "I'd like to start a conversation. Here's my starting sequence number."
  2. SYN-ACK — the server: "Got it, ready. Here's mine, and I acknowledge yours."
  3. ACK — the browser: "Acknowledged. Let's talk."

Only after this does any HTTP data actually move. The reason for the trouble is that HTTP sits on top of TCP specifically for reliability — TCP guarantees data arrives in order and without loss, retransmitting anything that goes missing. For a webpage, a corrupted or out-of-order response would be useless, so that guarantee is worth the small extra round trip.

Ports, and why HTTP lives on 80

An IP address gets you to the right machine. It doesn't tell you which program on that machine should handle the request — that's what a port is for, a number identifying a specific service.

HTTP traditionally uses port 80, HTTPS uses 443, mail servers often sit on 25 or 587, SSH on 22. None of this is physics — it's convention, so clients know where to knock without guessing.

Put an IP and a port together and you get a socket — 193.100.100.10:80. That exact pairing is what identifies "this service, on this machine," and it's what your TCP connection is actually built against.

None

Anatomy of a request

This is where things get genuinely useful, because everything you'll ever do in Burp involves reading and editing a request like this one:

GET /profile?id=104 HTTP/1.1
Host: abc.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Cookie: session=8f3a2c9e1b7d4f6a
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Length: 0

The method (GET) is the action being requested. The path (/profile?id=104) is the resource, including query parameters — and that id=104 is exactly the kind of thing attackers probe when testing access control. What happens if you change it to 105?

Host says which site on the server is being targeted, since one IP can host many. User-Agent identifies the client software — easily spoofed, and often abused for fingerprinting. Cookie is data the server previously asked the browser to store and resend, usually to track a session. Authorization carries credentials, often a token. Content-Length is the size of the body in bytes — zero here, since GET requests typically don't carry one.

A POST adds a body below the headers — the actual payload, like login credentials or form data.

What methods are supposed to mean

Methods describe intent — what the client is actually trying to do.

None

"Safe" means the method shouldn't alter server state — GET is supposed to be read-only, not an action. "Idempotent" means calling it once or a hundred times leaves things in the same end state — deleting something that's already deleted still leaves it deleted. When developers break these expectations, like performing a delete through a GET request, it opens the door to CSRF and similar abuse, because GET requests are much easier to trigger — even just by loading an image tag.

What happens on the server side

Once your request lands, a chain of mostly invisible steps kicks off. The web server — Nginx, Apache, IIS — receives the raw request and figures out routing: which internal app or code path should handle /profile?id=104. From there, backend code runs: reading the parameter, checking authentication, usually querying a database for the relevant data. If that query isn't built carefully, this is exactly the moment SQL injection becomes possible. The backend assembles a response — static file, or more often dynamic HTML or JSON — and hands it back to the web server, which packages it as a proper HTTP response.

None of this is visible to you. You just see the page. But every step is a place where trust can be misplaced.

Anatomy of a response

Here's a realistic response to the request above:

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: application/json
Content-Length: 142
Cache-Control: no-store
Set-Cookie: session=8f3a2c9e1b7d4f6a; HttpOnly; Secure
{"id":104,"username":"alex_dev","email":"alex@example.com"}

The status line gives the protocol version, status code, and a human-readable reason. Server identifies the software — useful, and occasionally risky, for fingerprinting. Content-Type tells the client how to read the body. Cache-Control: no-store here means "don't cache this" — worth paying attention to, since weak cache configuration is a real source of leaked data. Set-Cookie is the server issuing or refreshing a cookie, with flags like HttpOnly (unreadable by JavaScript, blocking some XSS-based theft) and Secure (HTTPS only). And then the body — the actual payload.

A Location header shows up on redirects (3xx codes), and mishandled, it's a classic source of open redirect bugs.

Status codes, decoded

The first digit tells you the category: 1xx is informational and rarely seen directly, 2xx means success, 3xx means further action is needed, 4xx means the client did something wrong, 5xx means the server failed on a valid request.

None

Status codes are also a quiet source of intel during testing — a 403 versus a 404 on a guessed endpoint tells you very different things about whether something exists but is protected, or just isn't there.

Misconfigurations worth knowing

Beyond specific vulnerability classes, a handful of everyday mistakes show up constantly in real testing. Missing security headers, like Content-Security-Policy, leave open exactly the door those headers exist to close. Directory listing left on can expose a whole file structure. Verbose error messages leak stack traces and file paths that should never reach a client. Old methods like PUT or TRACE left enabled can allow actions nobody meant to expose. Cookies missing HttpOnly, Secure, or SameSite are easier to steal. Endpoints that should require auth sometimes just don't. Authenticated users sometimes reach data meant for someone else. Redirects get hijacked into phishing. CORS gets configured loosely enough that untrusted origins can read data they shouldn't. And Host header trust issues show up when an app uses the client-supplied Host value for things like password reset links, without checking it — letting an attacker point that link at their own domain.

None of this is exotic. It's the ordinary, everyday stuff that shows up in real bug bounty reports far more than anything flashy.

Where this leaves you

Every webpage you've ever loaded is the visible result of a request-response pair, sitting on top of DNS resolution, a TCP handshake, and structured text both sides agreed to follow. HTTP is stateless by design, which is why sessions and cookies exist as a patch on top of it. Methods describe intent, but applications don't always enforce it. Status codes tell a story, often more honestly than the page itself does. And nearly every serious vulnerability you'll study — in PortSwigger's Academy or anywhere else — traces back to a server trusting a request it shouldn't have.

Resist the urge to rush into payloads before this part feels solid. The strongest testers aren't the ones who memorized the most tricks — they're the ones who understand the conversation well enough to notice when something about it doesn't add up.

One thing we've quietly stepped around this whole time: everything described here — the request, the headers, the cookies, the Authorization token — travels as plain text. Anyone sitting on the network path between you and the server, in the right position, can read all of it.

So the obvious next question: if HTTP is this fundamental, why isn't it considered secure?

That's where the next post picks up — HTTPS, TLS, certificates, and the handshake that quietly protects nearly every request you send today. Once that's in place too, we'll open Burp Suite and start working through the PortSwigger labs for real.