---
{
  "title": "HTTP status codes",
  "summary": "Interpret HTTP status classes with response content, permission context, and actual state changes instead of treating success codes as security verdicts.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: HTTP semantics",
      "url": "https://www.rfc-editor.org/rfc/rfc9110.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

HTTP status codes group responses into informational, success, redirection, client-error, and server-error classes. Specific codes have defined semantics, but application implementations may also require context to interpret a business outcome. A 200 response does not automatically mean authorization was correct; a 403 can reflect an intended denial. Logs should include enough request and identity context to explain the action without exposing unnecessary secrets.

## In practice

An invalid form request returns a client-error status, while a valid concept page returns a successful response with the expected content.

## A common misunderstanding

Counting successful responses is not enough to establish legitimate use or completed data transfer.

## Check your understanding

What should a security test check alongside the status?

**Think it through:** The returned content, state change, permission decision, and relevant server-side evidence.

## A protocol outcome can hide a business outcome

Imagine a fictional academy API returns HTTP 200 with a structured message saying a progress update was rejected. Counting the response as a completed update would misrepresent the application behavior. The content and resulting state matter as well as the protocol status.

The reverse can also occur: a client loses a response after a server has committed an operation. Retrying without understanding application semantics can create duplicate effects. Transport and status observations are pieces of the outcome, not universal transaction receipts.

## Denials need identity and resource context

Suppose one learner receives a forbidden response while another receives the expected document. That can be correct enforcement if their permissions differ. If both should have identical access, investigate session context, resource ownership, and policy rather than assuming the status alone explains the discrepancy.

A security test should specify the actor, requested resource, action, and expected result. The same response code can be appropriate in one test and evidence of a problem in another.

## Monitoring benefits from careful grouping

A rise in server-error responses can indicate availability problems, but the affected route, deployment, dependencies, and request pattern determine the investigation. A surge in client-error responses could reflect a broken client, scanning, or a legitimate change in usage.

Do not label every unsuccessful request an attack or every successful one harmless. Correlate status distributions with service and identity context while avoiding unnecessary secret values in logs.

For a safe exercise, invent four API requests: authorized read, unauthorized read, invalid input, and a duplicate update. Define the expected status, body, and state change for each. Explain what you would inspect if the implementation returned an unexpected combination. The result is a testable account of application behavior rather than a memorized table of response numbers.

## Keep exploring

- [[http]]
- [[authorization]]
- [[web-architecture]]