How the web works (and where it breaks)

HTTP in one page

The web runs on HTTP, a request/response protocol. A client sends a request (method, path, headers, optional body); a server returns a response (status code, headers, body). It runs over TLS as HTTPS (covered in the cryptography topic), but the structure is the same.

Methods carry intent: GET (retrieve, should have no side effects), POST (submit/create), PUT/PATCH (update), DELETE (remove). The "GET should be safe" convention matters for security, since a state-changing GET is what makes some CSRF attacks trivial.

Status codes group by first digit: 2xx success, 3xx redirect, 4xx client error (401 unauthenticated, 403 forbidden, 404 not found), 5xx server error. Leaking detailed 5xx errors to users is an information-disclosure problem.

Headers carry security-relevant metadata: Set-Cookie, Authorization, and a family of security headers (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options) covered in the defences chapter.

The statelessness problem

HTTP is stateless: each request is independent and the server remembers nothing between them by default. But applications need to know "this is the same logged-in user as a moment ago." That gap is bridged by sessions, and how it's bridged is the source of a huge share of web vulnerabilities.

The usual mechanism:

1. You log in; the server creates a session and sends back a session ID in a cookie.
2. Your browser automatically attaches that cookie to every subsequent request to the site.
3. The server looks up the session ID to know who you are.

The session ID is therefore as good as your password for the duration of the session. Steal it (via XSS, sniffing, or a predictable ID) and you hijack the session without needing a password. Cookie protection matters for exactly that reason.

Cookies and their security flags

A cookie is a small named value the browser stores and returns. Several flags determine how safely:

• HttpOnly: the cookie is not readable by JavaScript. This is the key defence that stops an XSS payload from stealing the session cookie.
• Secure: the cookie is only sent over HTTPS, so it can't be sniffed on a plaintext connection.
• SameSite (Strict / Lax / None): controls whether the cookie is sent on cross-site requests. Lax or Strict is the primary modern defence against CSRF, because the attacker's site can no longer cause the cookie to ride along.

A session cookie should typically be HttpOnly; Secure; SameSite=Lax. Knowing why each flag exists, and which attack each blocks, is exam gold, and it matters in the real world.

The same-origin policy

The same-origin policy (SOP) is the browser's foundational security boundary. An origin is the triple of scheme + host + port (https://example.com:443). Script running on one origin cannot read responses from a different origin. Without SOP, any site you visited could read your webmail or bank session in another tab, making the entire model of having multiple sites open at once unsafe.

CORS (Cross-Origin Resource Sharing) is the controlled, deliberate relaxation of SOP: a server can opt in to allowing specific other origins to read its responses, via Access-Control-Allow-Origin headers. Misconfigured CORS (e.g. reflecting any origin, or * with credentials) re-opens the hole SOP exists to close, and is a common finding.

Crucially, SOP restricts reading responses, not sending requests. Your browser will still happily send a request to another origin with its cookies attached, though it won't let the calling script read the reply. That asymmetry is exactly what CSRF exploits: the attacker doesn't need to read anything, only to cause a state-changing request to fire.

Client vs server: who can you trust?

The single most important security mindset for web: anything that happens in the browser is under the attacker's control. Client-side JavaScript validation, hidden form fields, disabled buttons, price values in the page: all can be modified with browser dev tools or replayed with a tool like Burp Suite. Client-side checks are a usability nicety; all security decisions must be enforced server-side. A great many web vulnerabilities reduce to "the developer trusted the client."

Quick recall

• HTTP is stateless; sessions (a session ID in a cookie) restore continuity and become the prime theft target.
• Cookie flags: HttpOnly (blocks JS/XSS theft), Secure (HTTPS only), SameSite (blocks CSRF). Know which attack each stops.
• Same-origin policy: scripts can't read another origin's responses (scheme+host+port). CORS opts into exceptions; misconfigured CORS undoes SOP.
• SOP blocks reading responses, not sending requests; that gap is where CSRF lives.
• Never trust the client; enforce every security decision on the server.