How Insecure Client-Side State Management Led to a Critical BFLA in a Healthcare Platform

During a recent authorized security assessment of a live (Private), AI-powered healthcare management platform, I identified a critical Broken Function Level Authorization (BFLA) vulnerability (OWASP API5:2023).

By analyzing the application's React frontend bundle and manipulating local session storage values, I escalated privileges from a standard Doctor account to a full System Administrator. This flaw exposed tenant metrics, administrative controls, and system-wide management features.

This write-up covers the discovery process, static analysis, exploitation proof-of-concept (PoC), and the required backend remediation.

1. Static Code Analysis & Discovery

The application was built as a Single Page Application (SPA) using React 18 and React Router v7. During initial recon, inspecting the page source code revealed a single minified JavaScript bundle serving the entire application architecture:

<script type="module" crossorigin src="/assets/index-QESwW2hV.js"></script>

<script type="module" crossorigin src="/assets/index-QESwW2hV.js"></script>

Key Findings in the Bundle:

Hardcoded Hidden Routes: Deobfuscating the React Router configuration revealed an administrative login portal (/portal-****) and hidden management interfaces (/admin-*****, /admin-*****, /admin-**********).
Client-Side Authorization Check: Route guards (<Ze role="admin">) relied heavily on reading user attributes directly from browser storage:

const currentUser = JSON.parse(sessionStorage.getItem("currentUser"));

const currentUser = JSON.parse(sessionStorage.getItem("currentUser"));

2. Analyzing the Session State

Upon authenticating as a standard clinician, the application initialized two key items in sessionStorage:

accessToken: A JWT string used for API authorization.
currentUser: A JSON object storing user metadata, including ID, name, email, and role: "doctor".

{
  "id": "fec231c2-ac4c-47de-bd27-6eba1679ae26",
  "role": "doctor",
  "specialization": "Cardiology",
  "status": "approved"
}

{
  "id": "fec231c2-ac4c-47de-bd27-6eba1679ae26",
  "role": "doctor",
  "specialization": "Cardiology",
  "status": "approved"
}

3. Privilege Escalation (PoC)

To test the authorization enforcement between the client application and the API backend:

Step 1: Client-Side Role Manipulation

Using Browser Developer Tools (F12 →Application → Session Storage), I modified the role key inside the currentUser JSON string from "doctor" to "admin".

{
  "role": "admin"
}

{
  "role": "admin"
}

Step 2: Unlocking Administrative Interfaces

Refreshing the dashboard caused the React application to re-evaluate the local state. The UI immediately rendered the Super Admin navigation drawer (مشرف عام / Super Admin), displaying high-level system controls.

Step 3: Verifying Broken Function Level Authorization (BFLA)

In a secure system, modifying local state should only alter UI rendering, while backend endpoints reject privileged actions with HTTP 403 Forbidden.

However, navigating to administrative routes triggered API requests to endpoints such as:

GET /api/v1/admins/dashboard/stats
GET /api/v1/admins/doctors
GET /api/v1/admins/subscriptions

The backend processed these requests using the standard user's bearer token and responded with HTTP 200 OK, returning full administrative data, organization breakdowns, and system-wide metrics.

4. Root Cause Analysis

The flaw stemmed from two architectural issues:

Frontend Role Reliance: The UI treated client-editable storage (sessionStorage) as a source of truth for routing decisions.
Missing Backend Authorization Middleware: The REST API endpoints under /api/v1/admins/* checked whether a valid JWT was provided, but failed to enforce server-side Role-Based Access Control (RBAC) middleware to verify if the claims associated with the token possessed administrative scope.

5. Remediation & Verification

The Fix: Server-Side RBAC

The engineering team resolved the issue by implementing strict, server-side RBAC middleware across all /api/v1/admins/* endpoints.

# Example: Server-side role enforcement (FastAPI/Python)
@router.get("/admins/dashboard/stats")
async def get_admin_stats(
    current_user: User = Depends(get_current_admin_user) # Verifies role == "admin" from verified JWT
):
    return await fetch_dashboard_stats()

# Example: Server-side role enforcement (FastAPI/Python)
@router.get("/admins/dashboard/stats")
async def get_admin_stats(
    current_user: User = Depends(get_current_admin_user) # Verifies role == "admin" from verified JWT
):
    return await fetch_dashboard_stats()

Verification

During re-testing on the production environment:

Client-side state was manipulated to role: "admin".
The UI attempted to fetch administrative data.
The API backend validated the signed JWT claims, identified the user as a doctor, and rejected all administrative API calls with HTTP 403 Forbidden.

Key Takeaways for Developers

Never Trust the Client: Client-side storage (localStorage, sessionStorage, cookies) can be modified by the user at any time.
Enforce Authorization at the API Layer: Every API endpoint must independently verify user scopes and permissions on the server for every incoming request.
Store Sensitive Tokens Securely: Use HttpOnly, Secure, and SameSite cookies to prevent token theft via Client-Side Scripting.

Responsible Disclosure Note: This vulnerability was reported to and patched by the engineering team prior to the publication of this article. All sensitive identifiers, domain names, and personal data have been sanitized.

Contents