A web application flaw where an attacker manipulates a single-page app's path or route to reach content that should be restricted. The weakness appears when the client decides access or route behaviour without a backend check, allowing hidden views or data to be exposed.
Expanded Definition
Client-Side path traversal is a browser-side routing flaw where an attacker alters a route, path, or location parameter in a single-page application to reach content the application should have kept hidden. Unlike classic server-side path traversal, the issue is not about reading files from a filesystem. It is about the client making trust decisions that should have been enforced by the backend.
This term is most often encountered in modern web applications that use JavaScript frameworks for navigation, lazy-loaded views, or route-based access control. The weakness emerges when the application assumes that obscured routes, UI state, or client-side guards are sufficient protection. In practice, that means sensitive pages, data panels, or workflow steps can sometimes be reached by changing the URL or manipulating app state. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework does not name this flaw directly, but its access control and application integrity controls are the right lens for preventing it.
Definitions vary across vendors when they describe whether the issue is a routing problem, an access control problem, or a broken authorization pattern. NHIMG treats it as a client-side trust failure with direct security impact. The most common misapplication is assuming that hiding a route in the front end is equivalent to enforcing authorization, which occurs when backend verification is missing or incomplete.
Examples and Use Cases
Implementing route protection rigorously often introduces additional backend checks and token validation, requiring organisations to weigh user experience and development speed against stronger authorization assurance.
- A customer portal loads account sections through route fragments, and a user manually changes the path to view another customer’s billing page because the server never re-checks entitlement.
- An internal dashboard uses hidden navigation tabs for admin functions, but the underlying API accepts direct requests to those views without verifying role membership.
- A single-page app fetches document previews based on a route parameter, and a modified URL exposes files that should require a higher authorization tier.
- A workflow application reveals later-stage forms when a client flag changes, but the backend does not confirm the user has completed the required approval steps.
- A security team reviewing browser-side access can use the same logic as broader web control guidance in OWASP testing resources and NIST control mapping to verify that sensitive routes are not only hidden, but actually protected.
Why It Matters for Security Teams
Client-Side Path Traversal matters because it turns the browser into a decision-maker for authorization, and the browser cannot be trusted to protect sensitive application paths. When the client controls navigation to restricted content, attackers can often discover hidden functionality, access unauthorized data, or bypass workflow gating without needing to exploit the server directly.
For security teams, the practical lesson is that route hiding, menu suppression, and front-end guards are usability features, not security controls. Real protection must come from server-side authorization, strong session validation, and consistent checks on every sensitive request. This is especially important in identity-heavy applications where role changes, delegated access, or non-human identities may interact with APIs behind the UI. If the front end and backend disagree about privilege, the application creates an authorization gap that can be abused quietly and at scale. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that access decisions belong in enforceable controls, not presentation logic.
Organisations typically encounter the real impact only after a user demonstrates access to content that was assumed to be unreachable, at which point client-side path traversal becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control principles apply when route access is trusted on the client. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement is the core control family implicated by this routing flaw. |
| OWASP Non-Human Identity Top 10 | NHI apps often expose route-driven admin and API views through weak client trust. | |
| NIST SP 800-63 | AAL2 | Stronger session assurance reduces abuse of client-side navigation bypasses. |
| NIST Zero Trust (SP 800-207) | PDP/PEP | Zero trust requires policy enforcement points outside the client for each request. |
Treat route-based access as an authorization boundary and validate it for human and non-human identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
