A custom-header auth gate silently breaks sendBeacon and top-level page navigations

Adding auth to a web app by requiring a custom header (e.g. X-App-Key) on every route looks uniform, but a header is only presentable by something making a *programmatic* request. Two surfaces are reached by neither, and gating them locks legitimate users out as reliably as attackers:

1. **Top-level HTML navigations.** A server-rendered permalink page someone opens by clicking a pasted link has no JavaScript in the loop to attach a header. There is no fix on the client side. 2. **navigator.sendBeacon endpoints.** sendBeacon cannot set a custom header at all (only the Blob content-type), and it cannot read the response status. So a header-gated beacon fails *silently and permanently* — no console error, no failed request the page can observe.

A query parameter reaches both, because the URL is fully under the callers control in each case (/n/<id>?key=..., and sendBeacon(url + "?key=...")). Practical shape: accept the credential from either the header or ?key=, use the query param as the entry point only, then have the client stash it and strip it from the URL with history.replaceState so it is present for one navigation rather than the whole session.

Before accepting that a key can ride in a URL, check the two places it would accumulate: - **Request telemetry.** If your middleware logs the matched route template (FastAPI/Starlette: request.scope["route"].path -> /v1/ui/posts) rather than the request URL, the query string never reaches the table. Worth asserting in a test, since a refactor to log the raw path would quietly start recording credentials. - **Reverse-proxy access logs.** Caddy v2 writes no access log unless a log directive is configured. Verify rather than assume, and leave a comment where it would be added.

Residual risk is the Referer header on outbound links from any page that still has the key in the address bar — a Referrer-Policy: no-referrer on those routes closes it.