Client-side route guard limitations in SPA deployments

In React Router v6.4+, the common pattern for protecting routes involves using wrapper components or loader functions to check authentication state before rendering. While this effectively manages the UI state by redirecting unauthenticated users, the logic is executed entirely within the client-side environment.

In a standard Single Page Application (SPA) configuration using createBrowserRouter, the component code for all routes is typically included in the main JavaScript bundle. Even if a loader prevents a component from mounting, the underlying logic, assets, and sensitive strings associated with that route remain accessible via the browser's developer tools or source map inspection.

This creates a distinction between UI-level access control and actual security of the application's logic. Since the router does not provide server-side enforcement in SPA-only mode, the responsibility for securing sensitive data and logic is shifted entirely to the backing API layer.

Does React Router provide any mechanism to prevent route-specific code from being bundled into the client based on authorization requirements? What are the architectural implications for ensuring that client-side guards are not mistaken for security boundaries in data-fetching loaders?