Sensitive data not persisted in browser storage unencrypted

CMMC 2.0 MP.L1-3.8.3 (NIST 800-171r2 3.8.3) covers controlled access to sensitive data. Storing authentication tokens or JWT strings in localStorage or sessionStorage makes them accessible to any JavaScript executing on the page — including injected third-party scripts and XSS payloads. Unlike HttpOnly cookies, browser storage offers no protection against script-based exfiltration. CWE-922 (Insecure Storage of Sensitive Information) and OWASP A02 (Cryptographic Failures) both apply. A token stored in localStorage that encodes user role and email exposes the user's identity and access level to any script that runs in the same origin.

Deliver authentication tokens as HttpOnly cookies set by the server — client code never touches the token value. For UI state that requires user info (display name, role label), fetch it from a dedicated endpoint rather than caching sensitive data in browser storage:

// DO NOT do this:
// localStorage.setItem('auth_token', response.token)

// Instead: server sets the cookie on login response
// Set-Cookie: session=<token>; HttpOnly; Secure; SameSite=Lax

// For UI-only user info:
const [user, setUser] = useState<User | null>(null)
useEffect(() => {
  fetch('/api/auth/me').then(r => r.ok ? r.json() : null).then(setUser)
}, [])

Audit all localStorage.setItem and sessionStorage.setItem calls in the codebase — non-sensitive UI preferences (theme, sidebar state) are acceptable; anything that identifies the user, their role, or their access credentials is not. Cross-reference with the authentication-verify check to confirm the session cookie flags are correctly set.