[BUG / SECURITY]: Client-side Route Guard and Identity Bypass via LocalStorage Manipulation
Description
The application relies on localStorage values (userType and userId) for client-side routing access control and to dynamically fetch user data. A user can easily bypass route-guards and impersonate other users/roles by manually modifying their local storage properties in the browser developer console.
Locations affected
- components/Auth/AuthCheck.js
- pages/doctor/dashboard.js
- pages/doctor/alerts.js
- pages/appointments.jsx
Steps to Reproduce
- Visit the home page (unauthenticated).
- Open the browser Developer Console.
- Run:
localStorage.setItem("userType", "doctor");
localStorage.setItem("userId", "impersonated-doctor-id");
localStorage.setItem("username", "Dr. Impostor");
- Navigate manually to
/doctor/dashboard.
- The
AuthCheck component will allow access because it validates the existence of the userType value directly from local storage.
- The dashboard attempts to retrieve patients using these spoofed IDs.
Expected Behavior
Access control and authentication details should be verified on the server side using secure session claims (e.g. Clerk token or Firebase Session cookies) instead of easily modifiable local storage values.
Proposed Solution
Refactor client-side layout guards to consume the global authentication state from useUser() (Clerk) or UserContext instead of querying localStorage.
[BUG / SECURITY]: Client-side Route Guard and Identity Bypass via LocalStorage Manipulation
Description
The application relies on
localStoragevalues (userTypeanduserId) for client-side routing access control and to dynamically fetch user data. A user can easily bypass route-guards and impersonate other users/roles by manually modifying their local storage properties in the browser developer console.Locations affected
Steps to Reproduce
/doctor/dashboard.AuthCheckcomponent will allow access because it validates the existence of theuserTypevalue directly from local storage.Expected Behavior
Access control and authentication details should be verified on the server side using secure session claims (e.g. Clerk token or Firebase Session cookies) instead of easily modifiable local storage values.
Proposed Solution
Refactor client-side layout guards to consume the global authentication state from
useUser()(Clerk) orUserContextinstead of queryinglocalStorage.