How HTTP works — unicorn

In a nutshell HTTP is the language a browser speaks to a web server. The browser sends a request ("give me the page"), the server sends a response (the page itself plus service information). Everything you do on the web is a stream of such request-response pairs. Web pentesting is, in essence, reading and altering these messages.

Every web interaction is a pair: your request, the server's response.

What HTTP and HTTPS are

HTTP (HyperText Transfer Protocol) is an application-layer protocol (L7 — see OSI & TCP/IP models), a set of rules for exchanging web content. It works on "the client asked, the server answered."

HTTPS is the same HTTP wrapped in TLS encryption. It gives three things:

Confidentiality — an outsider on the path can't read the exchange.
Integrity — the data can't be quietly swapped along the way.
Authenticity — the certificate proves you're talking to that exact site, not a fake.

Analogy: HTTP is a postcard any postman can read. HTTPS is a sealed envelope with the sender's seal.

HTTP is "memoryless" (stateless)

The key feature: HTTP does not remember previous requests. The server handles each request as if seeing this client for the first time. That keeps servers simple and fast, but creates a problem: how does a site "remember" that you're logged in? The answer — cookies and sessions (below).

What a request is made of

Three parts:

1. The request line — method, path, version:

GET /index.html HTTP/1.1

2. Headers — service key-value pairs:

Host: example.com
User-Agent: Mozilla/5.0 ...
Cookie: session=abc123

3. Body — data, if any. Usually empty for GET; for POST (submitting a form) the sent data lives here.

What a response is made of

1. The status line — version and code:

HTTP/1.1 200 OK

2. Headers — content type, length, cookies:

Content-Type: text/html
Set-Cookie: session=abc123
Content-Length: 1024

3. Body — the content itself: an HTML page, an image, JSON.

HTTP methods

A method = what to do with the resource:

Method	Action	Where the data is
GET	retrieve	in the URL (after `?`)
POST	send/create	in the request body
PUT	replace/create at an address	in the body
DELETE	delete	—
HEAD	like GET, but headers only, no body	—

The practical takeaway GET puts parameters right in the link: search.php?q=password. Links end up in browser history, in server logs, in the Referer header. So passwords and tokens are sent by POST (in the body), not by GET.

Status codes

The first digit sets the group:

Code	Meaning	When you see it
200 OK	success	the page was served
301 / 302	redirect (permanent / temporary)	redirect to another address
401 Unauthorized	login needed	not logged in
403 Forbidden	access denied	the path exists, but you may not
404 Not Found	not found	no such path
500 Internal Server Error	the server broke	a bug in the site's code

For pentesting: telling 401/403/404 apart matters. 404 — the path isn't there. 403 — the path exists, access is closed (already a finding). 500 — the server choked on your input (sometimes a sign of injection). Response codes are what directory brute-forcing runs on → Directory brute-forcing.

Headers worth knowing

In a request (from the browser):

Host — which site is wanted. Dozens of sites live on one IP; Host says which exactly.
User-Agent — what the client is (browser and version). Easily forged — scanners disguise themselves this way.
Cookie — the saved cookies, sent to the server.
Authorization — auth data (e.g. Bearer <token>).
Referer — which page you came from (careful: whatever was in the URL can "leak" here).

In a response (from the server):

Content-Type — what the content is (text/html, application/json, image/png).
Set-Cookie — the server asks you to save a cookie.
Content-Length — the body's size.
Server — sometimes gives away the web server's name and version (a hint for an attack).

Cookies and sessions — how a site "remembers" you

Since HTTP is memoryless, a recognition mechanism is needed. That's cookies:

You enter a login/password, the browser sends them by POST.
The server checks and replies: Set-Cookie: session=abc123.
The browser saves that cookie.
On every following request the browser adds Cookie: session=abc123 itself.
From that value the server knows "this is the one who logged in five minutes ago" — and doesn't ask for the password again.

The session cookie is essentially a temporary "pass." And here's the whole point for security: whoever holds a valid session cookie is the user — the password is no longer needed. Hence:

Stealing cookies via XSS.
The HttpOnly flag — forbids reading the cookie from JavaScript (protection against theft via XSS).
The Secure flag — the cookie is sent only over HTTPS (won't leak over plain HTTP).
Session interception / forgery attacks.

Why this is the foundation of web pentesting

Almost every web attack is a manipulation of HTTP requests:

Burp Suite intercepts the request between browser and server, you change it and send it on.
Injections (SQLi, XSS) — slip something malicious into a request parameter.
Auth bypass — change a parameter/cookie and get someone else's access.
Directory brute-forcing — read the response codes for different paths.

Without understanding how a request is built, you don't understand what exactly you're editing. That's why HTTP is what you keep coming back to.

This is the whole game for web pentesting Burp Suite lets you pause and edit that request before it arrives; SQLi/XSS slip payloads into it; auth bypass edits a cookie inside it. Understand the request and you understand what you're attacking.