What is the difference between 401 and 403?

A 401 means the request lacks valid authentication credentials, and the client may retry with credentials. A 403 means the server understood the request and the credentials but refuses to authorise it; re-authenticating will not help.

Why can 403 vs 404 be a security concern?

Returning 403 Forbidden confirms a resource exists but is off-limits, which leaks its existence to an attacker. For sensitive paths, many teams return 404 instead so unauthorised users cannot distinguish a hidden resource from a missing one.

Are 4xx and 5xx responses cached?

By default most error responses are not cached, but 404, 405, 410 and a few others are heuristically cacheable per RFC 9111 unless you send explicit Cache-Control headers. Always set Cache-Control on error responses you do not want stored.

Should I use 301 or 308 for a redirect?

Use 301 or 308 for permanent moves and 302 or 307 for temporary ones. The 307 and 308 codes guarantee the HTTP method is preserved, whereas historically 301 and 302 were sometimes rewritten to GET by clients.

Is this data fetched from a server?

No. The entire status-code table is bundled into the page, so lookups work instantly and offline with no network request.

What is the HTTP Status Code Reference & Security Implications?

A complete offline reference for registered HTTP status codes with plain-English descriptions, correct use cases, common misuse patterns, security implications such as 403 vs 404 information disclosure, and default caching behaviour. Bundled as static data — no network request. It runs free in your browser on Gera Tools, with nothing uploaded.

HTTP Status Code Reference & Security Implications

Name: HTTP Status Code Reference & Security Implications
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

HTTP status codes are the three-digit numbers a server returns to tell a client what happened to its request. Choosing the right one matters for correctness, caching and security — a misused 403 can leak the existence of hidden resources, and a 200 returned for an error breaks client retry logic. This reference explains each registered code with its correct use, common misuse, security implications and default caching behaviour, all bundled offline.

The five classes

Status codes are grouped into five classes by their first digit:

1xx Informational — the request was received and is continuing. 100 Continue tells a client with Expect: 100-continue that it may send a large request body.
2xx Success — the request succeeded. 200 OK is the most common; 201 Created signals a new resource was made; 204 No Content means success with no body to return.
3xx Redirection — further action is needed. 301 and 308 are permanent; 302 and 307 are temporary; 304 says a cached copy is still fresh.
4xx Client error — the client made a bad request. 400 is a malformed request; 401 needs authentication; 403 is authorised but refused; 404 is not found; 429 is rate-limited.
5xx Server error — the server failed. 500 is an unhandled exception; 502 and 504 are gateway problems; 503 is overload or maintenance.

How the tool works

Type a number (e.g. 404), a class prefix (e.g. 4xx), or a keyword (e.g. redirect or unauthorized). The tool filters a bundled, offline dataset and shows the reason phrase, correct usage, common misuse, security notes and default caching behaviour for each match.

Choosing the right 4xx code

The 4xx class has more subtlety than it first appears:

Code	When to use
`400 Bad Request`	The request body or query is malformed; validation failed
`401 Unauthorized`	No credentials were provided; the client may retry after authenticating
`403 Forbidden`	Credentials are valid but the action is not permitted; re-auth will not help
`404 Not Found`	The resource does not exist (or you are hiding a `403`)
`405 Method Not Allowed`	The method is not allowed; include `Allow: GET, POST`
`409 Conflict`	The request conflicts with current state (e.g. duplicate key)
`410 Gone`	The resource existed but has been permanently removed
`422 Unprocessable Content`	The syntax is valid but the semantics fail (REST APIs often prefer this to `400`)
`429 Too Many Requests`	Rate limit exceeded; include `Retry-After`

Security implications: 403 vs 404

Returning 403 Forbidden for a protected path confirms that the path exists to an unauthenticated caller. For sensitive paths (admin panels, internal APIs, user-data endpoints), many teams return 404 Not Found to unauthenticated requests so an attacker cannot enumerate protected resources. Once authenticated, the real 403 or 200 is returned. This is sometimes called “security through obscurity” but is a legitimate defence-in-depth measure when the existence of a path is itself sensitive information.

Caching notes

Per RFC 9111, several status codes are heuristically cacheable even without an explicit Cache-Control header: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, 451, 501. This means a 404 response without Cache-Control may be cached by browsers and CDNs for a short period. If you expect a resource to appear soon, send Cache-Control: no-store on the 404 to prevent stale negative caching.

Common misuses

200 with an error body — some older APIs return 200 OK with {"error": "not found"} in the body. This breaks HTTP caching, retry logic and every HTTP-aware tool.
500 for validation errors — validation failures are the client’s fault, not the server’s. Use 400 or 422.
404 for auth failures on public paths — if a resource genuinely does not exist, 404 is correct; hiding a 403 with 404 is only appropriate for sensitive paths. Using 404 everywhere is a pattern that frustrates legitimate API consumers.