BanGUI/Docs/Tasks.md at 93021500c348dffa8889da2830572e1ccbb5f0aa

Files

Lukas 93021500c3 TASK-033: Remove session token from JSON response body

Fixes a critical security vulnerability where the session token was
being returned in the JSON response body of POST /api/auth/login.
This exposed the token to JavaScript, allowing malicious scripts to
steal it and bypass the HttpOnly cookie protection.

Changes:
- Backend: Remove 'token' field from LoginResponse model (auth.py)
- Backend: Update login() endpoint to return only 'expires_at'
- Frontend: Update LoginResponse type to exclude 'token' field
- Backend: Update test helper _login() to extract token from cookie
- Backend: Update test cases to verify token is NOT in response body
- Documentation: Add section 'Authentication Endpoints' in Backend-Development.md
- Documentation: Update Web-Development.md to explain HttpOnly cookie benefits

Security benefit: Session tokens are now only accessible via HttpOnly
cookies, protected from JavaScript access, XSS attacks, and malicious
third-party scripts. The frontend continues to use only the cookie for
authentication.

All auth tests pass (23 tests). Type checking and linting pass with
zero errors.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

2026-04-26 19:38:33 +02:00

2.3 KiB

Raw Blame History

Severity: Medium

Where found

backend/app/routers/auth.py — login() returns LoginResponse(token=signed_token, expires_at=expires_at) in the JSON body and sets the HttpOnly cookie. backend/app/models/auth.py — LoginResponse.token field.

Why this is needed

The LoginResponse JSON body contains the full signed session token. JavaScript running on the page (including third-party analytics scripts or a future XSS injection) can read the response body from a fetch() call and store the token in localStorage or a non-HttpOnly cookie. The Bearer-header authentication path (Authorization: Bearer <token>) then allows using that extracted token, completely bypassing the protections provided by the HttpOnly cookie.

Goal

Prevent the session token from being accessible to JavaScript when using cookie-based authentication.

What to do

For browser SPA consumers: Remove the token field from LoginResponse. The HttpOnly cookie is the only token the browser needs.
If an API-first (non-browser) token flow is required, create a separate endpoint POST /api/auth/token that returns a token in the body and does not set a cookie. Document this endpoint as "for programmatic API clients only, not for browser use".
Update the frontend — verify that AuthProvider does not use response.token (confirmed: it currently does not).

Possible traps and issues

Any existing API client that relies on the token in the LoginResponse body will break. Check tests.
The expires_at field in LoginResponse is useful for the frontend to know when to prompt for re-login — this can remain.
The Bearer-token path in require_auth (Authorization: Bearer) remains functional for programmatic clients using the dedicated token endpoint.

Docs changes needed

Features.md — document the authentication flow (cookie for browser, token endpoint for API clients).
Backend-Development.md — authentication endpoint design.
Web-Development.md — document that the frontend uses only the HttpOnly cookie.

Doc references

Features.md — authentication
Backend-Development.md — auth router design
Web-Development.md — AuthProvider

2.3 KiB Raw Blame History

TASK-033 — Session token returned in JSON body alongside HttpOnly cookie