Overview of HTTP Status Codes

HTTP status codes are three-digit numbers that indicate the outcome of a client's request to a server during an HTTP transaction. They are part of the response message sent by the server to inform the client whether their request was successful or encountered an error.

These status codes are critical for both developers and penetration testers. In cybersecurity, manipulating HTTP requests and analyzing the specific status code returned is the foundational step for reconnaissance, directory fuzzing, and vulnerability exploitation. These codes are grouped into five main categories: informational responses, successful responses, redirects, client errors, and server errors.

NOTE: While the HTTP/1.1 specification includes both a numeric code and a text message (e.g., "404 Not Found"), modern protocols like HTTP/2 and HTTP/3 have entirely eliminated the textual message component to reduce unnecessary network overhead. The numeric code is the only reliable source of truth.

1xx: Informational Responses

An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response.

Code	Message	Description
101	Switching Protocols	The requester has asked the server to switch protocols, and the server has agreed to do so (e.g., upgrading from HTTP to WebSockets). Security Context During penetration testing, 101 requests are often monitored for Cross-Site WebSocket Hijacking (CSWSH) vulnerabilities if the server fails to validate the `Origin` header during the handshake.

2xx: Successful Responses

Status codes that indicate that the server successfully processed the request.

Code	Message	Description
200	OK	The server successfully processed the request. Generally, this means that the server provided the requested page. Security Context A 200 OK on administrative panels (`/admin`) or sensitive configuration files (`/.env`) during automated fuzzing is a critical finding indicating unauthorized access or data exposure.
204	No Content	The server sent a valid reply to a client request that contains header information only (i.e., does not contain any message body). Security Context Often used in REST APIs for successful `DELETE` requests. Missing authorization checks on endpoints returning 204 can lead to silent Insecure Direct Object Reference (IDOR) deletions.

3xx: Redirection Responses

Further action is needed to fulfill the request. Often, these status codes are used for routing.

Code	Message	Description
301	Moved Permanently	The requested page has been permanently moved to a new location. When the server returns this response, it automatically forwards the requestor to the new URI specified in the `Location` header. Security Context A 301 from `http://` to `https://` is a secure best practice. However, if user input controls the `Location` header, it results in an Open Redirect vulnerability, heavily used in phishing campaigns.
302	Found (Temporary)	The server is currently responding to the request with a page from a different location, but the requestor should continue to use the original location for future requests. Security Context A 302 redirect after submitting a login form is standard. Attackers ensure they intercept 302s through proxies like BurpSuite to analyze session cookies assigned during the transition.

4xx: Client Error Responses

These status codes indicate that there was an error in the request which prevented the server from being able to process it, often indicating insufficient privileges or malformed syntax.

Code	Message	Description
401	Unauthorized	The request requires authentication. Before a resource can be accessed, the client must verify their identity (usually via an Authorization header). Security Context Continuous 401s originate primarily during Credential Stuffing or Brute Force attacks. A sudden spike in 401s on an API endpoint indicates an active attack against user accounts.
403	Forbidden	The server understood the request but refuses to authorize it. Unlike a 401, providing authentication credentials will make no difference because the user's role lacks permission. Security Context A 403 response confirms that the requested file or directory actually exists, but is protected. Testers will often attempt to bypass 403 restrictions using HTTP verb tampering (e.g., swapping `GET` for `POST` or `TRACE`) or manipulating headers like `X-Forwarded-For: 127.0.0.1`.
404	Not Found	The server can't find the requested page. For instance, the server often returns this code if the request is for a page that doesn't exist on the server. Security Context While harmless individually, mass 404 scanning across hidden directories (`/.git/`, `/backup.zip`) is the primary method attackers use to map the invisible architecture of a target system. Soft 404s (where the server returns a 200 OK but displays a "not found" message) can deceive automated security scanners.
429	Too Many Requests	The client has sent too many requests in a given amount of time. Security Context A 429 response proves that Rate Limiting infrastructure (like an API Gateway or WAF) is active and successfully mitigating DoS or brute force attempts. If an attacker cannot trigger a 429 after 10,000 requests, the server is highly vulnerable to exhaustion attacks.

5xx: Server Error Responses

These status codes indicate that the server is aware that it is currently incapable of performing the request, often due to an internal crash, overload, or downstream failure.

Code	Message	Description
500	Internal Server Error	The server encountered an unexpected condition that prevented it from fulfilling the request. Security Context A 500 error is a goldmine for attackers. It indicates that malicious payload injection (like SQL Injection `id=1'` or extremely long buffer overflows) successfully broke the backend application logic. Furthermore, poorly configured servers may leak stack traces within the 500 response body, exposing database schemas or filesystem paths to the attacker.
502	Bad Gateway	The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. Security Context Often seen in massive microservice environments like AWS API Gateway + Lambda. A 502 indicates that while the public-facing proxy is healthy, the internal service (like a database or rendering engine) has collapsed, potentially due to a targeted Server-Side Request Forgery (SSRF) or resource starvation attack.

HTTP Status Code Checker