CWICP study materials
CWICP study resources

CWICP: Web Application Fundamentals and HTTP

CWICP · Work through your exam, one topic at a time.

All guide sections

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-Type plus X-Content-Type-Options (MIME sniffing), Content-Security-Policy, and Set-Cookie attributes Domain, Path, Secure, HttpOnly, SameSite.
  • State is layered. TCP/TLS connection, HTTP connection reuse, cookies, server-side sessions, and browser storage each survive different events. HttpOnly hides 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=Lax blocks all cross-site requests; it does not block top-level GET navigations.
  • Forgetting that Host is 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.