Web Application Fundamentals and HTTP
The Web Application Fundamentals and HTTP domain establishes the vocabulary the rest of the exam assumes. Questions here ask you to read a raw request/response pair, decide which tier is responsible for an observed behavior (browser, CDN/reverse proxy, application server, framework, database), and reason about how protocol semantics become security consequences.
Protocol rules to know cold
- Methods carry semantics. GET and HEAD are safe; GET, PUT, DELETE, HEAD are idempotent; POST is neither. A state-changing GET is simultaneously a caching defect and a CSRF amplifier.
- Status codes are class contracts. 401 = unauthenticated (expect
WWW-Authenticate); 403 = authenticated but denied. 405 vs 404 distinguishes method filtering from absent routes. - Headers are the control plane.
Host(virtual hosting, cache poisoning, reset links),X-Forwarded-For/Forwarded(trust boundaries),Content-TypeplusX-Content-Type-Options(MIME sniffing),Content-Security-Policy, andSet-CookieattributesDomain,Path,Secure,HttpOnly,SameSite. - State is layered. TCP/TLS connection, HTTP connection reuse, cookies, server-side sessions, and browser storage each survive different events.
HttpOnlyhides a cookie from JavaScript, not from the network. - HTTP/2 and HTTP/3 change framing, not semantics. Binary multiplexed streams and HPACK/QPACK compression move smuggling opportunities to the HTTP/1.1-to-HTTP/2 translation layer in front ends.
Worked example
The response is HTTP/1.1 200 OK with body {"error":"not authorized"} and Set-Cookie: sid=abc; Path=/; HttpOnly. Reasoning: the status line reports success while the application layer reports denial, so scanners keyed on status codes will miss the access-control behavior. The cookie lacks Secure and SameSite, so it will travel over plaintext HTTP if port 80 answers and will accompany cross-site top-level navigations. Because the status is 200, a shared cache keyed only on URL may store the denial body and serve it to a different user.
Traps that cost marks
- Treating 403 as a dead end - forced browsing to 403 endpoints still reveals which resources exist.
- Assuming
SameSite=Laxblocks all cross-site requests; it does not block top-level GET navigations. - Forgetting that
Hostis attacker-controlled and frequently reflected into password-reset links. - Confusing authentication (who you are) with authorization (what you may do) when interpreting 401 and 403.
- Calling Base64-encoded or JSON-wrapped data encrypted.