Define and enforce a security boundary for state-changing API routes #2

New issue

Closed

opened 2026-08-23 22:37:27 +02:00 by kristofferopsahl · 1 comment

kristofferopsahl commented

2026-08-23 22:37:27 +02:00

Collaborator

Finding

The FastAPI app exposes unauthenticated state-changing and computationally expensive routes:

POST /api/squad writes data/squad.json.
POST /api/override writes overrides and re-simulates a club.
POST /api/firm-up runs full simulations and writes the projection cache.
POST /api/refresh performs a full rebuild and writes the cache.
POST /api/refresh-live performs an outbound fetch and mutates process state.

The Windows launcher currently relies on uvicorn defaulting to loopback, but the application itself does not enforce that deployment assumption. A future --host 0.0.0.0, reverse proxy, container, or LAN exposure would make the controls available to any caller.

Suggested direction

Document and mechanically enforce one supported boundary: local-only binding, or authentication/authorization for mutating routes.
If browser credentials are introduced, include CSRF protection and restrictive origin handling.
Separate read-only serving routes from administrative/rebuild operations so deployment policy is explicit.
Add a startup guard or production configuration that refuses an unsafe public bind without protection.

Acceptance criteria

State-changing and expensive routes are inaccessible to unauthorised remote callers.
The supported trust model is documented and covered by tests.
Read-only local usage continues unchanged.

## Finding The FastAPI app exposes unauthenticated state-changing and computationally expensive routes: - `POST /api/squad` writes `data/squad.json`. - `POST /api/override` writes overrides and re-simulates a club. - `POST /api/firm-up` runs full simulations and writes the projection cache. - `POST /api/refresh` performs a full rebuild and writes the cache. - `POST /api/refresh-live` performs an outbound fetch and mutates process state. The Windows launcher currently relies on uvicorn defaulting to loopback, but the application itself does not enforce that deployment assumption. A future `--host 0.0.0.0`, reverse proxy, container, or LAN exposure would make the controls available to any caller. ## Suggested direction - Document and mechanically enforce one supported boundary: local-only binding, or authentication/authorization for mutating routes. - If browser credentials are introduced, include CSRF protection and restrictive origin handling. - Separate read-only serving routes from administrative/rebuild operations so deployment policy is explicit. - Add a startup guard or production configuration that refuses an unsafe public bind without protection. ## Acceptance criteria - State-changing and expensive routes are inaccessible to unauthorised remote callers. - The supported trust model is documented and covered by tests. - Read-only local usage continues unchanged.

kristofferopsahl added the

security

architecture

priority: high

labels

2026-08-23 22:37:27 +02:00