HTTP 404 Not Found is an HTTP status code meaning the server could not find the requested resource. It is returned when a URL points to a page, file, or API endpoint that does not exist or is not available at that path, while the server itself is reachable.
What the status code means in practice
HTTP 404 Not Found is not a transport failure or a server outage. It means the server understood the request, but the specific resource named by the path does not exist there, or is no longer available at that location.
That distinction matters because the origin can be healthy while a page, file, or endpoint is missing. A 404 therefore often points to URL design, routing, content lifecycle, or deployment issues rather than infrastructure unavailability.
Why 404s matter for users and systems
For users, a 404 is usually the visible symptom of a broken bookmark, stale link, renamed page, deleted asset, or mistyped path. For applications, the same response can interrupt navigation, break integrations, or hide the fact that a client is calling an endpoint that was never created or has been retired.
In APIs, repeated 404s can reveal poor client assumptions, outdated documentation, or mismatched versions between producers and consumers. For security teams, the pattern is often a signal to distinguish ordinary content drift from probing activity that is discovering which paths exist and which do not.
Common causes and how to interpret them
Most 404s come from simple causes: link rot, incorrect relative paths, deleted content, misconfigured reverse proxies, changed route names, or deployment mismatches between environments. In a well-run site, some 404s are expected and harmless, especially when users type old URLs or follow external links that have not been updated.
The same response can also be intentional. Applications sometimes return 404 instead of exposing whether a resource exists, reducing information disclosure. In those cases, the response is part of the access pattern, not just a navigation error.
How teams reduce 404s and recover cleanly
Good practice is to treat 404s as both a content-management issue and a telemetry source. Stable URL design, redirects for renamed resources, accurate API versioning, and routine link checks reduce avoidable failures. The goal is to keep legitimate references working while preserving a clear signal when a resource truly is absent.
Operationally, teams should watch for new 404 spikes after releases, migrations, or redirects changes, because those often indicate broken references or incomplete cutovers. For public APIs, a controlled 404 response can also help clients fail safely when they request unsupported paths, as long as the behaviour is documented and consistent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | 404s often expose missing or retired API paths that should be inventoried and tracked. |
| Recommendation — Inventory API routes and retire unused paths deliberately so stale requests fail in a controlled way. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and Network Services are Monitored to Detect Potential Cybersecurity Events | Unexpected 404 patterns can indicate probing, broken integrations, or abnormal client activity worth monitoring. |
| Recommendation — Monitor repeated 404 patterns to separate routine user error from suspicious discovery activity. | ||
| OWASP ASVS | V13 — Configuration | Incorrect routing, redirects, and deployment settings commonly produce 404 responses. |
| Recommendation — Validate routing and deployment configuration so expected resources resolve to the intended location. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application paths, redirects, and error handling are part of secure application behaviour that affects 404 outcomes. |
| Recommendation — Test application routing and error handling so missing resources are handled consistently and safely. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org