HTTP, HTTPS, and How the Web Really Works

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: A huge share of all security work — employed or freelance — is finding and fixing bugs in web applications. Web apps are everywhere, they’re exposed to the entire internet, and they’re written fast. To attack or defend them you must know the language they speak: HTTP. The good news — HTTP is just text. Once you can read a request and a response, the web stops being mysterious.

Part 1: The Problem

When you start bug bounty hunting or web app pentesting (Phase 2), you will spend your days reading and modifying HTTP requests. If HTTP feels like a black box, every technique — injecting a payload, tampering with a cookie, forging a request — will feel like guesswork.

It isn’t guesswork. HTTP is a simple, readable, text-based conversation. This section makes that conversation legible.

Part 2: The Concept — HTTP Is a Request and a Response

The web runs on a dead-simple pattern: a client (your browser) sends a request; a server sends back a response. That’s it. One round trip.

   ┌─────────┐   ──── REQUEST ───►   ┌─────────┐
   │ Browser │                      │ Server  │
   │ (client)│   ◄─── RESPONSE ───   │         │
   └─────────┘                      └─────────┘

A single web page triggers many of these — one for the HTML, then one each for every image, script, and stylesheet. But each is the same simple request/response pair.

Part 3: Anatomy of an HTTP Request

A request is just text, in a fixed shape:

GET /search?q=cats HTTP/1.1          ← request line
Host: example.com                    ┐
User-Agent: Mozilla/5.0              │ headers
Cookie: session=abc123               │ (metadata)
Accept: text/html                    ┘
                                     ← blank line
(body — empty for GET, has data for POST)

Three parts:

1. The request line — METHOD PATH VERSION The method says what you want to do:

2. The headers — metadata about the request. Key ones for security:

• Host — which website on the server you want.
• Cookie — small stored values sent back to the server (see Part 5).
• User-Agent — identifies your browser/OS.
• Authorization — credentials, when present.

3. The body — the actual data being sent. Empty for GET; for POST it holds form fields, JSON, etc.

Why this matters: Attacking a web app is changing parts of this request — the path, a header, a cookie, the body — and watching how the server reacts. Every Phase 2 technique is a variation on that.

Part 4: Anatomy of an HTTP Response

The server replies in a matching shape:

HTTP/1.1 200 OK                      ← status line
Content-Type: text/html              ┐
Set-Cookie: session=abc123            │ headers
Server: nginx                         ┘
                                      ← blank line
<html>... the actual page ...</html>  ← body

The most important part is the status code — a three-digit number summarizing what happened:

Why this matters: Status codes are how an attacker probes an app. Try to access an admin page: 403 means “exists but you’re blocked”; 404 means “not there”; 200 means “you got in.” Each code leaks information. Defenders, in turn, learn to not leak too much through them.

Part 5: Cookies and Sessions — How Websites “Remember” You

HTTP has a quirk: it is stateless. Each request is independent; the server, by default, has no memory that you logged in two clicks ago.

So how do you stay logged in? Cookies.

1. You log in (a POST with your username and password).
2. The server verifies you and replies with a header: Set-Cookie: session=abc123.
3. Your browser stores that cookie.
4. On every future request, your browser automatically adds Cookie: session=abc123.
5. The server sees the cookie and thinks: “abc123 — that’s the logged-in user.”

LOGIN
  Browser → Server:  POST /login  (username + password)
  Server  → Browser: 200 OK  +  Set-Cookie: session=abc123

EVERY REQUEST AFTER
  Browser → Server:  GET /dashboard   Cookie: session=abc123
  Server  → Browser: 200 OK  (your personalized dashboard)

Why this is enormous for security: That session=abc123 value is your identity to the server. If an attacker steals it, they become you — no password needed. This single fact is the root of session hijacking, the reason XSS is dangerous, and the motivation for half of web security. Sit with it.

Part 6: What HTTPS Actually Does (and Doesn’t)

HTTP sends everything as plain, readable text. Anyone positioned between you and the server — on the same wifi, at an ISP, on a compromised router — can read every request and response, including passwords and cookies.

HTTPS is HTTP wrapped in encryption (a layer called TLS). It does three things:

1. Encryption — eavesdroppers see scrambled noise, not your data.
2. Integrity — data can’t be secretly modified in transit.
3. Authentication — a certificate proves the server is really who it claims (this is the padlock in your address bar).

But be precise about what HTTPS does NOT do:

• It does not hide who you’re talking to. An observer still sees the server’s IP address and usually the domain name.
• It does not make the website itself secure. An HTTPS site can still be riddled with SQL injection, broken access control, and every other bug in Phase 2. HTTPS protects the pipe, not the building at the end of the pipe.
• It does not protect you if your own machine is compromised.

   HTTP                          HTTPS
   ┌──────┐  readable   ┌──────┐  ┌──────┐  scrambled  ┌──────┐
   │client│════════════►│server│  │client│≈≈≈≈≈≈≈≈≈≈≈≈►│server│
   └──────┘             └──────┘  └──────┘             └──────┘
   eavesdropper sees              eavesdropper sees
   EVERYTHING                     ONLY noise + the destination

A frequent beginner (and client) misconception is “we have HTTPS, so we’re secure.” You will correct that misconception many times in your career.

📓 Key Terms

🧪 Hands-On Lab

You’ll use your browser’s built-in Developer Tools — the same panel professionals live in.

Task 1 — Open the Network tab. On any website, press F12 (or right-click → Inspect), then click the Network tab. Reload the page. You’ll see every HTTP request the page made — often dozens.

Task 2 — Read a real request and response. Click any one request in the list. Explore the panels:

• Headers — see the request line, the request headers, the response status code, and the response headers. Find the Host header. Find the Content-Type.
• Try to spot a Set-Cookie or Cookie header somewhere in the list.

Task 3 — Watch a login set a cookie. Go to any site where you have an account. Open the Network tab, then log in. Find the login request (often a POST). Look at its response headers for Set-Cookie. Then click any later request and confirm your browser is now sending that cookie back automatically. You just watched Part 5 happen live.

Task 4 — Collect status codes. While browsing, watch the Status column. Find a 200. Visit a page that doesn’t exist to trigger a 404. If you can, find a 301/302 redirect. Match each to the table in Part 4.

Task 5 — Inspect a certificate. Click the padlock in your address bar → view the certificate. See who issued it and what name it’s valid for. This is the “authentication” part of HTTPS.

⚠️ Common Mistakes

• Believing HTTPS = secure app. HTTPS protects data in transit. The application can still be deeply vulnerable. Internalize this now.
• Underestimating cookies. A session cookie is a full identity. “It’s just a cookie” is how people end up explaining a breach.
• Ignoring GET vs POST semantics. GET parameters sit in the URL (logged, cached, shared); POST data sits in the body. Sensitive data in a GET URL is a real, common bug.
• Not knowing the dev tools. The Network tab is a daily-use tool for the rest of your security career. Learn it now, not later.

✅ Recap & What’s Next

• The web is a simple request/response conversation in plain-text HTTP, with methods, headers, status codes, and a body.
• HTTP is stateless; cookies and sessions are how sites remember you — which makes a session cookie equal to your identity.
• HTTPS encrypts and authenticates the connection, but does not make the application itself secure.

Next (0.4): We go back to the network and learn to think in terms of attack surface — every service, every open port, every protocol that an attacker could knock on.