Refuse cross-site changing requests from a proxy sign-in #715

Part of #701.

Scope

A request signed in through the sign-in proxy that would change something must come from the console's own page. Another website cannot make a signed-in person's browser release a lease, drain a worker or start a command. Requests with a Simlock token are not affected.

In short

A browser can send the proxy's cookie on a request another page starts: a page on a sibling address of the same site, or any site when the cookie is set SameSite=None. So a request whose identity came from the proxy (an "ambient" identity) and changes something must carry Sec-Fetch-Site: same-origin, which the browser itself sets and a page cannot fake. Anything else gets 403.

Browsers send Sec-Fetch-Site only to an https:// address or to loopback. Behind a proxy served over plain http:// on a network name, every changing request signed in through the proxy is refused. The console sends no changing request today, so it loses nothing; a script carrying the proxy's cookie would. The docs say to serve the proxy over HTTPS.

flowchart LR
  R[request with an identity] --> A{ambient and not GET/HEAD/OPTIONS?}
  A -->|no| OK[continues, as today]
  A -->|yes| S{"Sec-Fetch-Site: same-origin? (new)"}
  S -->|yes| OK
  S -->|no or missing| F[403]

Word: ambient identity, one the browser attaches by itself (the proxy's cookie, turned into a JWT by the proxy), as opposed to a token the caller sends on purpose.

The 403 body: { "error": { "code": "FORBIDDEN", "message": "Cross-site request refused: a request signed in through a sign-in proxy must come from the console" } }.

If this goes wrong, another site could make a signed-in person's browser release leases or drain workers.

Technical spec

Facts

Commit ccb50353.

Modules touched

Search: F2's, plus rg 'requireAuth' src (one definition, one use).

• src/http/auth.ts: the check, after the identity is set, before next(). One place, so it covers every route and mount.
• docs/HTTP-API.md: one paragraph and the 403.

Contract and event changes

none. Reads one more request header, Sec-Fetch-Site, compared to the exact value same-origin; any other value or absence is refused.

Other code on the same state

State: none (a per-request check). Search: rg -i 'sec-fetch|origin' src/http: no hit today. The console sends no changing request (F5).

Failure modes

State: none written.

Rules in play

• Architecture rule 10, one place: the check lives once, in requireAuth, keyed on ambient, not on the strategy.
• Architecture rule 21: src/http reads ambient, never the strategy's name.
• Safety rule 10, a claim on the wire: unknown or missing fails closed.
• ADR 0033 §5.

Tests

Seam: createHttpApp with a fake Auth whose identity is ambient or not; model on src/http/app.test.ts.

• src/http/app.test.ts: with an ambient identity, POST /v1/workers/w/drain and DELETE /v1/leases/x with Sec-Fetch-Site cross-site, same-site, none, Same-Origin, same-origin, cross-site and missing are 403 with the exact body and nothing is dispatched; with same-origin they are dispatched.
• src/http/app.test.ts: with an ambient identity, PUT and PATCH to a test mount with cross-site are 403 and the mount is not called; with same-origin the mount is called; GET, HEAD and OPTIONS to the mount with cross-site reach the mount.
• src/http/app.test.ts: with an ambient identity, GET /v1/leases with cross-site is dispatched.
• src/http/app.test.ts: with a non-ambient (token) identity, DELETE /v1/leases/x with cross-site is dispatched.
• e2e/proxy-auth.test.ts (Sign in through a sign-in proxy's signed JWT #714's file): against a real gateway, a good JWT on POST /v1/workers/no-such-worker/drain with cross-site is 403 with the CSRF message; with same-origin it reaches the dispatcher and answers 404 UNKNOWN_WORKER.

Done when

• The tests above pass; pnpm test:e2e e2e/proxy-auth.test.ts passes.
• docs/HTTP-API.md states the rule, the 403 message, and that a proxy sign-in needs the proxy served over HTTPS (or loopback) for changing requests.

Out of scope

• CORS headers; Origin allow-lists.
• Any rule for token-signed requests.

Depends on

• Sign in through a sign-in proxy's signed JWT #714

Written by an agent.