Overview
HTTP status codes tell you the outcome of a request. In security testing they are a primary signal — how a server responds (200 vs 401 vs 403 vs 404) often reveals whether a resource exists and whether access control is working. This lesson covers status codes for web security.
Learning objectives
- Recall the five status-code classes and key codes.
- Interpret codes as security signals.
- Distinguish authentication from authorization responses.
Core concept
Status codes group by first digit: 2xx success, 3xx redirect, 4xx client error, 5xx server error. Security-relevant codes include:
- 200 OK — success.
- 301/302 — redirect (the
Locationheader says where). - 401 Unauthorized — authentication required/failed (you are not logged in).
- 403 Forbidden — authenticated but not permitted.
- 404 Not Found — resource does not exist.
- 429 Too Many Requests — rate limited.
- 500 — server error (may leak details).
How it works
Codes let a tester infer server behavior without seeing internals. The 401 vs 403 distinction reveals whether the issue is authentication or authorization. Differences between 403 and 404 can disclose whether a resource exists (a 403 on a hidden path implies it is there). 429 indicates rate limiting is present (relevant to brute-force resistance). Bursts of 5xx can signal instability or that a payload caused an error. Observing how codes change as requests are modified is a core testing technique.
Practical example
Probing /admin while logged out returns 401 (authentication needed). Logged in as a normal user, it returns 403 (authenticated, not allowed) — confirming the endpoint exists and is access-controlled. A different hidden path returning 403 rather than 404 hints the resource is present. Meanwhile, requesting a login repeatedly and receiving 429 shows rate limiting is defending against brute force.
Cybersecurity relevance
Status codes are among the most-used signals in web assessment: mapping hidden endpoints (403 vs 404), diagnosing access control (401 vs 403), detecting rate limiting (429), and spotting error conditions (5xx) that may indicate a successful injection or information leak. Defenders should also ensure error responses are consistent and do not leak whether resources/accounts exist, which relates to enumeration defenses covered later.
Common mistakes
- Confusing 401 and 403 — 401 is "not authenticated," 403 is "authenticated but not permitted."
- Ignoring what 403-vs-404 differences reveal about resource existence.
- Overlooking 5xx responses, which may signal injection or information disclosure.
Key takeaways
- Classes: 2xx success, 3xx redirect, 4xx client error, 5xx server error; key codes include 200, 301/302, 401, 403, 404, 429, 500.
- 401 vs 403 distinguishes authentication from authorization; 403 vs 404 can reveal whether a resource exists; 429 indicates rate limiting.
- Status codes are core testing signals; defenders should keep error responses consistent to avoid leaking existence of resources or accounts.
Check your understanding
- What does receiving a 403 (instead of 404) on a hidden path suggest to a tester?
- What is the practical difference between a 401 and a 403 response?