Module 1 · HTTP & Web Fundamentals

Last updated: May 1, 2026

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":"[email protected]","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.

HTTP performance — the request lifecycle that determines everything

A typical browser request goes through six stages: DNS resolution, TCP/TLS connection, request send, server processing, response receive, content render. DNS: 20-200 ms; cached responses are free. TCP + TLS handshake: 1-3 round trips on TLS 1.2, 1 RTT on TLS 1.3, 0 RTT on resumed TLS 1.3. Geographic distance matters: India-to-Mumbai PoP ~10 ms; India-to-US-east ~250 ms. Server processing: depends on app efficiency, database, cache. Content render: blocked until critical CSS/JS loads.

HTTP security headers — the cheap controls every site should set

Eight headers that materially reduce attack surface:

Strict-Transport-Securitymax-age=31536000; includeSubDomains; preload forces HTTPS and resists downgrade.

Content-Security-Policyrestricts resource loads; nonces for inline scripts; strict-dynamic for trusted-script chains.

X-Content-Type-Optionsnosniff blocks MIME-sniffing tricks.

X-Frame-OptionsDENY or CSP frame-ancestors blocks clickjacking.

Referrer-Policystrict-origin-when-cross-origin minimises referrer leakage.

Permissions-Policyexplicitly opts out of geolocation, camera, mic if unused. Cross-Origin-Opener-Policy and

Cross-Origin-Embedder-Policyenable cross-origin isolation for high-precision timers and SharedArrayBuffer. Test with securityheaders.com; aim for A+ grade. Misconfiguration is the most common finding in Indian VAPT reports — and the cheapest to fix.

Cookies in 2026 — flags, partitioning, and same-site reality

Modern cookies must set Secure (HTTPS only), HttpOnly (no JS access), SameSite=Lax or SameSite=Strict (CSRF defence). Chrome enforces SameSite=Lax by default; iframe-embedded apps relying on cross-site cookies need SameSite=None; Secure + CHIPS partitioning (Partitioned attribute). For session cookies, also set short expiry (1-4 hours), regenerate ID on login, and clear on logout. Cookies vs JWT-in-localStorage: cookies are XSS-safer (HttpOnly hides them from script), JWT-in-localStorage is XSS-fatal (any script can read). The 2026 default for web apps: HttpOnly session cookies + CSRF token; JWT only for cross-domain APIs where cookies are impractical.

India regulatory mapping — what the IT Act, DPDP, and sector rules demand

For Indian web apps: DPDP Act 2023 requires lawful basis for data collection (typically consent or specified-purpose); web forms collecting PII must surface a privacy notice in plain language. IT Act §43A / Rules 2011 require “reasonable security practices” — ISO 27001 is the most-cited proxy. RBI Cyber Security Framework Annex 1 (banks) and SEBI CSCRF (capital markets) call out web app security explicitly.

CERT-In 2022 directiveweb/SaaS operators retain logs 180 days.

BIS / IS 17428Indian privacy management standard increasingly cited in tenders. Practitioner translation: every webapp pentest report should map findings to these frameworks; Indian customers want this overlay, not just OWASP labels.

Further reading

• MDN — HTTP overview
• OWASP Secure Headers Project
• web.dev — Cookies in 2024+
• Mozilla Observatory
• IS 17428 — Indian privacy standard

Additional FAQs

How fast should a typical Indian web page load?

Largest Contentful Paint under 2.5 s, First Input Delay under 100 ms, Cumulative Layout Shift under 0.1 (Core Web Vitals). On Indian 4G that needs Indian-region CDN + aggressive caching + critical-path CSS inlining. Page Speed Insights gives concrete fixes per page.

Should I disable HTTP and only allow HTTPS?

Yes — but redirect HTTP to HTTPS, do not just close port 80; otherwise old links break. Combine with HSTS preload so browsers refuse HTTP entirely after first visit.

Where do most beginners go wrong on HTTP?

Confusing client-side and server-side validation (always do both), trusting client-supplied headers (validate at the edge), and assuming HTTPS makes the app secure (it only secures transport — every input still needs validation).