HTTP Status Codes for Recon Learners

Status codes are sentences, not trophies.

When you map hosts under an authorized scope, an HTTP (or HTTPS) response often includes a status code: a three-digit number that summarizes how the server handled the request. Learners use them to triage — "is this alive?", "does it redirect?", "is access denied?", "is the app broken?" — not to celebrate "cracking" someone else's site.

Pair this lesson with Subdomain Finder: names first, then careful interpretation of responses only where you have permission.

The families (1xx–5xx)

Range	Role	Recon intuition
1xx	Informational	Rare in casual browsing; usually intermediate protocol signals.
2xx	Success	The server accepted and fulfilled the request (e.g. 200 OK with a page or API body).
3xx	Redirection	Follow or note the Location — staging may bounce to production; dig deeper only in scope.
4xx	Client error	401/403 often means "something is here but gated"; 404 may mean no content or a soft hide.
5xx	Server error	Upstream failure, misconfig, or overload — note it; do not hammer retries against live third parties.

Common codes you will see in labs:

• 200 — content returned; still inspect headers and body carefully.
• 301 / 302 / 307 / 308 — redirects; map the chain.
• 401 Unauthorized / 403 Forbidden — authentication or authorization barrier (different stories).
• 404 Not Found — no resource at that path (or a deliberate generic reply).
• 500 / 502 / 503 — server-side trouble; treat as a finding to document, not a reason to flood.

Reading codes in a learning / recon context

1. Alive vs interesting — a 403 on admin. can be more interesting than a blank 404 on a random path, in scope.
2. Consistency — identical custom error pages across hosts may hint at shared infrastructure.
3. Headers matter — server, CDN, and auth headers often explain the code better than the number alone.
4. Do not equate status with vulnerability — a redirect is not an exploit; a 500 is not remote code execution.

Ethics reminder

Checking HTTP status against arbitrary internet hosts without authorization is not "homework." Practice on:

• Your own lab VMs and containers
• Intentionally vulnerable training apps
• Programs that publish explicit testing rules

This site's demo uses fake statuses for a fixed demo.lab list. It never probes user-supplied real-world targets.

Next step

Open the demo below, filter by status class, and narrate each row as if you were writing a short lab note: host, code, hypothesis, and what you would ask next — still inside authorization.