HTTP status codes & security headers
Status codes grouped by class, the security-relevant ones, and the response headers that harden a site.
Status code classes
The first digit tells you the category:
| Class | Meaning |
|---|---|
| 1xx | Informational |
| 2xx | Success |
| 3xx | Redirection |
| 4xx | Client error |
| 5xx | Server error |
Codes worth knowing
| Code | Meaning | Security note |
|---|---|---|
| 200 | OK | - |
| 301 / 302 | Moved permanently / found (redirect) | Open-redirect risk if the target is user-controlled |
| 304 | Not modified | Cached response served |
| 400 | Bad request | Malformed input |
| 401 | Unauthorized | Not authenticated: credentials missing or invalid |
| 403 | Forbidden | Authenticated but not authorised: know the 401/403 distinction |
| 404 | Not found | Returning 404 (not 403) can hide the existence of a resource |
| 405 | Method not allowed | Wrong HTTP verb |
| 429 | Too many requests | Rate limiting in action (a good sign) |
| 500 | Internal server error | Verbose 500s leak internals (information disclosure) |
| 502 / 503 | Bad gateway / service unavailable | Often seen during outages or DoS |
401 vs 403: 401 means "I don't know who you are" (authenticate); 403 means "I know who you are and you still can't" (authorisation). This pair is a classic exam point.
HTTP methods
| Method | Purpose | Note |
|---|---|---|
| GET | Retrieve | Should be safe / no side effects; state-changing GETs enable CSRF |
| POST | Submit/create | - |
| PUT / PATCH | Replace / partially update | - |
| DELETE | Remove | - |
| HEAD | Headers only | - |
| OPTIONS | Allowed methods | Used in CORS preflight |
Security headers
The response headers that harden a web application:
| Header | What it does | Defends against |
|---|---|---|
Strict-Transport-Security |
Forces HTTPS for future visits | Protocol downgrade / SSL stripping |
Content-Security-Policy |
Restricts which sources scripts/resources may load from | XSS, data injection |
X-Content-Type-Options: nosniff |
Stops the browser guessing content types | MIME-sniffing attacks |
X-Frame-Options / CSP frame-ancestors |
Controls whether the page can be framed | Clickjacking |
Referrer-Policy |
Limits what's sent in the Referer header |
Leaking URLs/tokens |
Set-Cookie: HttpOnly |
Cookie unreadable to JavaScript | Session theft via XSS |
Set-Cookie: Secure |
Cookie sent only over HTTPS | Sniffing on plaintext |
Set-Cookie: SameSite=Lax/Strict |
Limits cross-site cookie sending | CSRF |
A secure session cookie
Set-Cookie: session=<random>; HttpOnly; Secure; SameSite=Lax; Path=/
HttpOnly: JS can't read it (XSS can't steal it)Secure: HTTPS only (can't be sniffed)SameSite=Lax: not sent on cross-site requests (CSRF defence)- the value itself must be long and from a CSPRNG, and rotate on login.
CORS in one line
The same-origin policy blocks scripts reading another origin's responses; CORS (Access-Control-Allow-Origin) lets a server opt specific origins back in. Reflecting any origin, or * together with credentials, re-opens the hole SOP exists to close, a common misconfiguration.