Security Posture of Modern SPA Routing

Literature review and controlled lab testing of common router patterns

Client route guards are presentation controls; bundles often leak privileged route inventories; history/query state can retain sensitive identifiers.

UI-only authz enables BOLA/IDOR and accelerates privileged-feature discovery.

Enforce server-side authorization on every sensitive operation; minimize privileged routes in public bundles; harden tokens and CSP.

Modern single-page applications (SPAs) move routing into the browser: the server often serves one shell document, and JavaScript decides which “page” to render from the URL. That architectural shift improves UX, but it routinely confuses teams about where authorization actually lives. This research note summarizes common SPA routing patterns, how they fail under a security review, and mitigations that hold up in production.

Methodology: literature review of common router designs (history API, hash routes, file-based meta routes), plus controlled lab observations on intentionally weak demos. Findings are qualitative — not a ranked CVE survey and not a claim about any specific vendor product.

Client-side route guards are not authorization

A typical SPA pattern:

1. User requests /app/admin/users.
2. CDN or origin returns index.html + JS bundles for all authenticated users (or even anonymously).
3. The router matches /app/admin/users and a beforeEach / loader guard checks user.role === 'admin' in memory.
4. If the check fails, the UI redirects to /login or /403.

From a product perspective this feels like security. From an assessment perspective it is presentation control. Anyone who can execute or rewrite client code — or call the underlying API directly — bypasses the guard.

Research takeaway: Treat client route guards as UX. Enforce authorization on every sensitive API and server action, keyed by session identity and object ownership — not by “did the router allow the component to mount.”

History state, deep links, and residual data

SPA routers store navigation state in:

• The URL path and query string (often logged by proxies, analytics, and Referer headers).
• history.state blobs (may hold IDs, filters, or even cached records).
• Client stores (Redux, Vuex, Zustand) hydrated from prior views.

Deep links are valuable for users and dangerous when they encode capability:

Lab pattern: map all routes from the client bundle, then replay each parameterized route against the API with alternate IDs and roles. UI redirects are irrelevant if GET /api/orders/18422 returns data.

Client bundle leakage

Bundlers frequently emit:

• Route tables and path strings for lazy-loaded admin screens.
• Feature flags and environment labels (staging, internalTools).
• GraphQL operation names and REST path constants.
• Occasionally hardcoded preview credentials or debug endpoints (configuration smell).

Even without secrets, route inventories accelerate attacks. Knowing /admin/impersonate exists is enough to start authorization tests.

Enumeration tips (authorized labs):

• Search built assets for /admin, role, permission, featureFlag.
• Inspect source maps if accidentally deployed to production.
• Diff bundles across releases to spot new privileged surfaces.

Framework-specific footnotes (non-exhaustive)

The framework brand matters less than whether each data fetch re-checks authorization.

Failure modes observed in weak labs

1. Guard on mount, fetch without authz — component redirects unauthenticated users, but the useEffect fetch already fired with a stolen cookie or no cookie against a public misconfiguration.
2. Role in JWT displayed client-side only — UI hides buttons; API trusts a forgeable claim or ignores object-level checks.
3. Optimistic UI exposing privileged actions — buttons render from cached role; server rejects late, but the action names and payloads taught the tester the API.
4. Open redirects via returnUrl — login flows honor ?next= into javascript: or off-site URLs when routers parse loosely.
5. Service worker / offline cache — privileged HTML fragments cached and later served to a different session on a shared browser profile.

Mitigations that actually move risk

1. Server-side authorization on every sensitive operation — same checks for browser, mobile, and API clients.
2. Do not ship privileged route modules to low-privilege users when feasible (separate bundles / gated SSR). Still never rely on absence of JS as authz.
3. Minimize secrets and internal pathnames in public bundles; keep debug routers out of production builds.
4. Prefer opaque tokens in paths; keep short-lived secrets out of query strings; use POST body or fragment carefully with full threat modeling.
5. Clear or avoid storing PII in history.state; rehydrate from the server on privileged screens.
6. Regression tests for BOLA on each new parameterized route — automated integration tests beat hoping the router guard is enough.
7. Content Security Policy and strict script inventory reduce the blast radius of XSS that would otherwise rewrite client guards.

Mapping to SPA routing authz reviews

A practical review checklist:

1. Extract client route list (manual or bundler artifact search).
2. Classify routes: public, authenticated, privileged, parameterized.
3. For each privileged/parameterized route, identify the API objects touched.
4. Attempt cross-user and cross-tenant access at the API layer.
5. Confirm error paths do not leak existence (user enumeration) unless product-accepted.
6. Verify logout clears in-memory stores and does not leave privileged fragments in BFCache unexpectedly.

Limitations of this note

• No claim of statistical prevalence across the industry.
• Framework APIs change; always verify against your major version.
• SSR/edge auth patterns can be strong when implemented carefully — this note targets the failure mode where teams believe client routing equals access control.

Related on Andrax

• Hands-On Tutorial: Exploiting & Fixing BOLA in REST APIs
• API Security Testing: Complete Guide for Pentesters
• Web Application Security Testing Guide