Fix auth session persistence with HttpOnly cookies and CSRF

REPORT.md

@@ -22,21 +22,26 @@ Performed a read-only static review of:
 
 ## Blocking Security Issues (Code-Level)
 
-### 3) Medium - Bearer token stored in browser sessionStorage
+### 3) Medium - Token persistence risk in browser storage (Remediated)
 
 Impact:
 
-- Any successful XSS on the frontend origin can steal bearer tokens and replay them.
+- Previously, a bearer token in browser sessionStorage could be stolen by a successful XSS in the frontend origin.
+- The codebase now uses HttpOnly session cookies plus CSRF protection, so tokens are no longer kept in browser storage.
 
 Exploit path:
 
-- Malicious script execution on app origin reads `sessionStorage` and exfiltrates `Authorization` token.
+- Previously: malicious script execution on app origin read `sessionStorage` and exfiltrated `Authorization` token.
 
 Evidence:
 
-- Token persisted in sessionStorage and injected into `Authorization` header: `frontend/src/lib/api.ts:39-42`, `frontend/src/lib/api.ts:61-67`, `frontend/src/lib/api.ts:84-95`, `frontend/src/lib/api.ts:103-112`.
+- Previous evidence in this scan no longer applies after implementation of cookie-backed auth in:
+  - `frontend/src/lib/api.ts`
+  - `backend/app/api/auth.py`
+  - `backend/app/api/routes_auth.py`
+  - `backend/app/main.py`
 
 Remediation:
 
-- Prefer HttpOnly Secure SameSite cookies for session auth, plus CSRF protection.
+- Implemented: HttpOnly Secure SameSite session cookies and CSRF protection with frontend CSRF header propagation for state-changing requests.
 - If bearer-in-JS remains, enforce strict CSP, remove inline script execution, and add strong dependency hygiene.