curl -I -o /dev/null -w "%{http_code}" https://example.com
HTTP 200 OK is the most common status code on the web — every successful page load, every successful API call, every successful form submission returns 200 (or another 2xx). It signals "the request succeeded; the response body contains what was requested". Despite being the "boring success" code, 200 has security and operational nuances worth understanding.
From a security perspective, 200 carries information about what attackers can reach: a 200 on /admin/ tells an attacker the admin panel exists and is reachable; a 200 on /.git/config reveals an exposed git repository; a 200 on a vulnerable endpoint returns the actual exploitation surface. Many web reconnaissance tools (gobuster, ffuf, dirsearch) specifically look for 200 responses to identify accessible content. The 200 itself is not the vulnerability, but it is the indicator that something further is exploitable.
On the defensive side, returning 200 for everything (including not-found and unauthorised conditions) is sometimes used as a security-through-obscurity tactic. This is generally counterproductive: it breaks legitimate caching and crawling behaviour, confuses monitoring tools, and rarely actually obscures attacker recon (response size and content patterns reveal the truth). Use the right status code for the right condition; let 200 mean what it is supposed to mean.
Tools like gobuster, ffuf, dirsearch send requests to common paths (/admin/, /backup/, /.git/, /wp-config.php.bak) and flag any 200 responses as accessible content. The 200 indicates "this exists and serves content"; further inspection determines whether the content is sensitive. Standard external pentest reconnaissance.
Functional testing of APIs verifies that valid requests produce 200 responses with the expected body content. Failed test cases (200 expected but 4xx received, or 200 with unexpected body) catch regressions before they reach production. Standard test framework pattern.
Load balancers and monitoring systems use HTTP 200 from health check endpoints to determine whether a backend is healthy. Returning 200 for the health check while the actual application is broken (because the health check is too shallow) causes traffic to be routed to broken instances. Health checks should verify actual application health, not just "the web server is responding".
CDNs cache 200 responses based on Cache-Control headers. Misconfigured Cache-Control with permissive settings (public, max-age=86400) on user-specific or sensitive responses can leak data via shared CDN caches. Always verify Cache-Control on 200 responses for personalised or sensitive content.
Hunters look for 200 responses that should not exist: exposed backup files, leaked configuration files, debug endpoints accidentally enabled in production, internal admin interfaces reachable from the public internet. The 200 is the indicator; the response body content determines whether it is a valid finding.
APIs that always return 200 with success/failure in JSON body break HTTP semantics. Use proper status codes — 4xx for client errors, 5xx for server errors, 2xx for actual success. Many tools (curl, fetch, monitoring systems) treat 200 as success regardless of body content.
A 200 response with user-specific content (cart contents, user dashboard, account details) cached by CDN with public Cache-Control leaks data to other users. Set Cache-Control: private for user-specific content, Cache-Control: no-store for sensitive content.
Health checks that just confirm the web server responds (without testing database, external dependencies, application logic) miss real failures. Load balancers route traffic to broken instances. Health checks should verify actual functionality.
A 200 on /admin/dashboard.php from an unauthenticated request means the admin panel is accessible without auth. Common WordPress and PHP application misconfiguration. Authentication checks should be enforced before any 200 response on protected endpoints.
Some sites return 200 with a "not found" page body for any URL. Confuses search engines (they index the soft 404 as legitimate content), confuses monitoring (no 404 spike when broken links appear), and wastes crawl budget. Use proper 404 status code.
Security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security) need to be on 200 responses to actually protect content. Missing headers on 200 (especially HTML responses) leaves XSS, clickjacking, and downgrade attack surface open.
200 OK — generic success with body. 201 Created — resource was created (used in REST APIs after POST). 202 Accepted — request accepted for processing, not yet completed. 204 No Content — success but no body to return (common for DELETE). 206 Partial Content — successful range request (used for resumable downloads).public, max-age=N for shared cacheable content. private, max-age=N for user-specific content (only browser cache, not CDN). no-store for sensitive content that should never be cached.curl -I https://example.com/path shows headers including status code. curl -o /dev/null -s -w "%{http_code}\n" https://example.com/path shows just the status code.