Module 1 · HTTP & Web Fundamentals 🔒

Every web attack — from the simplest parameter injection to the most subtle business-logic exploit — ultimately comes down to HTTP messages. The browser sends a request; the server sends a response. Everything in between that seems complex is just layers on top of this foundation.

If you want to test web applications competently, you must read HTTP fluently. Not “I know what GET and POST are” fluently — that’s surface reading. Fluently means: you can read a captured request and predict what the server will do, what it expects, where it might break, and what happens if a field is different. This module builds that fluency.

HTTP in one paragraph

HTTP is a stateless request-response protocol. The client (browser, mobile app, script) sends a request — a text message following a specific structure — to a server. The server processes it and sends a response — another structured text message — back. Each request-response pair is independent; the protocol itself doesn’t remember anything between requests. “Stateless” is the word that matters. Everything we’re going to exploit — sessions, authentication, authorization — is built on top of this stateless protocol to give it state. Where state is constructed, attackers find exploitable gaps.

Anatomy of a request

Here’s a typical HTTP request:

GET /api/users/42/profile HTTP/1.1
Host: app.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Firefox/125.0
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cookie: session_id=abc123def456; theme=dark

Break it down:

• Request line: GET /api/users/42/profile HTTP/1.1 — the method, path (including query string if any), and protocol version
• Headers: key-value pairs following the request line. Host is mandatory in HTTP/1.1 and up. Everything else is contextual.
• Blank line: separates headers from body
• Body: empty for GET requests. POST/PUT/PATCH bodies go here.

As a tester, every value in this request is a potential input to attack. The path (/api/users/42/profile) — swap 42 to 43 and see if you can read another user’s data (IDOR, covered in Module 6). The Authorization header — strip it, modify the JWT, try algorithm confusion. The Cookie — decode the session_id, test if the server validates it. The User-Agent — some apps parse this and store it in logs, and poorly-written log viewers have had XSS via User-Agent. Nothing in the request is “metadata” from an attacker’s perspective; everything is attack surface.

Anatomy of a response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 87
Set-Cookie: session_id=xyz789; HttpOnly; Secure; SameSite=Lax
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff

{"id":42,"name":"Alice","email":"alice@example.com","role":"admin"}

• Status line: HTTP/1.1 200 OK — protocol version, status code, status text
• Headers: response-specific. Note the security headers — Strict-Transport-Security, X-Content-Type-Options. We’ll dissect these.
• Body: the actual content. JSON here; could be HTML, XML, an image, anything.

Request methods — beyond GET/POST

Most developers can name GET and POST. Testers need the full list and their semantic differences:

Security implication: applications often implement authorization differently across methods. A GET /admin/users might be blocked for non-admins, but POST /admin/users might not be — the developer forgot to check. This is a real finding pattern. When you test, always probe every HTTP method against every endpoint you find.

Status codes that matter in security testing

• 200 OK — standard success. Doesn’t mean “safe” — it just means the server accepted the request.
• 301 / 302 / 307 — redirect. Watch for open redirects (a user-controlled URL that the server redirects to without validation — phishing enabler).
• 400 Bad Request — malformed input. Useful for fuzzing: does the server handle malformed input gracefully, or do you see internal errors leak through?
• 401 Unauthorized — not authenticated. Often confused with 403.
• 403 Forbidden — authenticated but not authorized. Distinguishing 401 vs 403 tells you whether credentials worked but permissions didn’t.
• 404 Not Found — resource doesn’t exist. But: note whether 404 comes before or after authorization. Some apps return 404 for resources the user shouldn’t even know exist (IDOR mitigation via obscurity).
• 500 Internal Server Error — something broke server-side. Error details in the response body can leak stack traces, framework info, query details. Extremely useful for reconnaissance.
• 429 Too Many Requests — rate limit hit. Important to know: how strict is the rate limiter? Per-IP, per-account, per-endpoint?

Headers you need to recognize

A non-exhaustive hit list of security-relevant headers:

• Authorization: Bearer <token> or Basic <base64> — authentication credentials. Modify these; observe responses.
• Cookie: ... — session state. Every value here is potentially tamperable.
• Content-Type: application/json — what the body is. Flip it to application/xml and some servers happily parse XML → XXE attacks are born here.
• X-Forwarded-For, X-Real-IP, X-Client-IP — client IP address when behind a proxy. Apps that trust these for rate limiting or access control are bypassable.
• Referer — previous page URL. Occasionally used for authorization (badly). Strip or modify.
• Host — target domain. Host-header injection can redirect password-reset emails to attacker-controlled domains.
• Origin — origin of cross-origin requests. CORS validation happens against this.
• Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — response-side security headers. Absence of these is a finding; weak configurations are findings; we covered this in the HTTP Header Analyzer tool.

Cookies, sessions, and state

HTTP is stateless. Web apps are not. The bridge is cookies.

A Set-Cookie header in a response asks the browser to store a name-value pair and send it back on subsequent requests to the same domain:

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Cookie flags you must understand:

• HttpOnly — blocks JavaScript access (document.cookie). Mitigates XSS-based session theft. Absence = finding.
• Secure — only sent over HTTPS. Absence = finding on sites with TLS.
• SameSite=Strict | Lax | None — controls whether the cookie is sent on cross-origin requests. Lax is the modern default. None requires Secure. CSRF attacks depend heavily on this setting.
• Path — restricts which paths the cookie is sent to. Weakly scoped paths can leak cookies to unintended endpoints.
• Domain — which domain the cookie is valid for. Subdomain leaks happen here.

Session management is the classic problem: how does the server recognise subsequent requests from the same client? Common patterns: server-side session IDs (the cookie is just a pointer to server state), self-contained tokens (JWT — the cookie contains all the state, signed). Each has different attack patterns. We’ll dive into both in Module 3.

TLS / HTTPS — what it actually protects

TLS provides three properties for data in transit:

1. Confidentiality — observers on the network can’t read the contents
2. Integrity — data isn’t modified in transit
3. Authentication — the client can verify the server’s identity (via the certificate)

TLS does not provide: client authentication (in most deployments — though mTLS does), protection once the data reaches the server, defense against any application-layer attack, or proof that the server’s code is trustworthy. “HTTPS means secure” is one of the most common misconceptions outside security. HTTPS means “the network can’t see it” — that’s it. Every vulnerability we’re about to study happens inside the HTTPS tunnel, after the TLS termination.

Exercises

Before moving to Module 2, internalise this material with three exercises:

1. Capture a request. Install Burp Suite Community (free). Configure your browser to proxy through it. Visit any web app (a real site you own, or a deliberately-vulnerable target like PortSwigger Web Security Academy labs). Examine 3-5 captured requests in detail. Identify: method, path, headers (purpose of each), body format, response status, security headers in the response.

2. Compare a GET and a POST. In the same app, find a form submission. Capture the GET rendering the form, then the POST submitting it. Note what changes in the request. What’s in the POST body that wasn’t in the GET?

3. Modify and resend. Right-click a captured request in Burp → “Send to Repeater”. Modify one header (e.g., change User-Agent, or add X-Forwarded-For: 127.0.0.1). Send. Does the response change? What did the app do with your modification?

Check your understanding

• Why is HTTP called “stateless”, and how do cookies bridge that?
• What’s the difference between 401 and 403?
• Which cookie flag prevents JavaScript access, and which XSS impact does that mitigate?
• What does TLS protect, and what does it not protect?
• Why should testers probe every HTTP method against every endpoint, not just the documented one?

Take the 20-question quiz below to confirm your understanding. Pass with 70%+ to mark this module complete. Unlimited retries.