Client-side route guard limitations in SPA deployments

Answer

No. React Router v6.4+ provides no mechanism to prevent route-specific code from being bundled into the client based on authorization requirements. Bundling and chunking are controlled by the build tool and React.lazy, not by the router. With createBrowserRouter in SPA mode, loaders, actions and guard components execute entirely in the browser. The router can redirect unauthenticated users for UI purposes but provides no server-side enforcement of access.

Confirmed facts

• React Router does not control what code is shipped to the client. Code splitting is a bundler concern.
• In a SPA configuration using createBrowserRouter, loaders and route elements run in the browser. They are UI/UX controls only.
• The router does not provide server-side enforcement in SPA-only mode. Security of data and logic must be enforced by the backing API layer.

Likely behavior

• Route-level code splitting via lazy route elements can defer download of a component until navigation, but the chunk remains part of the shipped application and is retrievable via DevTools or source maps once requested.
• Authorization cannot be used to conditionally exclude code at build time per user. The same bundle is served to all clients.
• Even if a loader redirects, the underlying logic, assets and sensitive strings associated with that route remain accessible in the client bundle.

Architectural implications for loaders

Client-side guards and loaders must not be mistaken for a security boundary.

• Loaders are convenient for UI state and data prefetch, but they run in the client. They can be bypassed by manipulating router state or by calling the API directly.
• Sensitive strings, implementation details and component logic are inspectable. Source maps, error messages and embedded environment variables can leak information.
• Actual access control belongs on the API and, where needed, on server-rendered or server-protected routes. The API must independently validate authentication and authorization tokens on every request used by a loader or action.

Minimal verification steps for this case

1. Inspect production build chunks with the bundler analysis tool to confirm which route components are in the initial and lazy chunks.
2. Test a protected route with an unauthenticated session and verify the loader runs in the browser and that the API rejects unauthorized data requests.
3. Review API endpoints used by loaders to ensure they independently validate authentication and authorization, not relying on client-side redirects.

One diagnostic detail that changes the recommendation: Are you deploying SPA-only with static hosting, or do you have a server-rendered entry point that can enforce access before code is sent? Server rendering or server-protected routes are the only way to avoid shipping protected code to unauthorized clients.