Topic starter
20/08/2026 5:30 pm
TL;DR: Client-side path traversal in single-page applications lets attackers manipulate URLs to reach hidden routes, expose sensitive data, or bypass frontend-only controls, according to Jscrambler. The security lesson is that route hiding is not authorisation, and server-side checks must remain the source of truth.
Editorial analysis by NHI Mgmt Group, based on content published by Jscrambler: “Client-Side Path Traversal in SPAs”.
Key questions
Q: What breaks when SPA route controls are not backed by server-side authorization?
A: Users can change the URL and reach views that were only hidden in the browser, because client-side routing is not a trusted security boundary.
Q: Why does client-side path traversal increase the risk of data exposure?
A: Because many SPA routes are tied to dashboards, user records, or settings pages that load sensitive content once the view is reached.
Q: What do security teams get wrong about hidden routes in SPAs?
A: They often assume that not showing a route in the UI means it is protected.
Practitioner guidance
- Enforce server-side authorisation on every protected route Require the backend to validate roles and entitlements before returning protected views or data, even when the frontend hides the route.
- Constrain dynamic routes with strict validation Use explicit route definitions and validate path parameters against fixed patterns so untrusted input cannot redirect navigation into restricted areas.
- Remove access decisions from browser state Do not store authorisation state in local storage, JavaScript variables, or other client-controlled logic that an attacker can alter.
Bottom line: Client-side path traversal in SPAs turns URL manipulation into a practical access-control bypass when authorisation is only enforced in the browser.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:17 pm
Client-side route hiding is a governance weakness, not a control. SPAs often present hidden routes as if they were protected, but concealment in the browser does not equal authorisation. The real governance problem is that teams confuse interface design with access policy, which leaves sensitive views exposed whenever client logic is bypassed. Practitioners should treat the browser as an untrusted delivery layer and keep enforcement on the server.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams secure SPAs that rely on dynamic routing?
A: Teams should use explicit route definitions, strict parameter validation, and backend authorisation checks for every protected resource. Dynamic path construction from untrusted input should be avoided, and any route that leads to sensitive data should fail closed when the server cannot confirm entitlement. That combination closes the gap between navigation and access control.
👉 Read our full editorial: Client-side path traversal in SPAs exposes hidden routes and data