An external laboratory posts signed result notifications to your practice's receiver endpoint — why does it need no CSRF check, and what keeps that exemption safe?

## What makes a forgery possible in the first place A cross-site forgery works because of one property: the credential is **ambient**. The user agent attaches it by itself, on the basis of where the request is going, so a page the practice did not write can cause an authenticated request to arrive at the practice's server. Every honest exemption follows from the same property, read backwards. Turn it around and the test becomes mechanical. For each route ask: **is there a credential a user agent will attach to a request that some other page initiated?** If the answer is no, an anti-forgery value defends nothing, because there is no way for a hostile page to produce an authenticated request there at all. ## The two exempt callers at the desk | Caller | Credential | Attached by | Can a hostile page produce it? | |---|---|---|---| | Front-desk staff | session cookie | user agent, automatically | It does not need to — the browser supplies it | | Laboratory receiver | signature over the exact request body | the calling program | No — it does not hold the key | | Microchip registry | long-lived machine secret in a request header | the calling program | No — it cannot read or guess the secret | The laboratory's client computes a signature over the bytes it is about to send, using a key only it and the practice hold. A page in a staff member's browser cannot compute that value, and no browser will attach it on the page's behalf. The registry client sets a machine secret in a request header; again the value has to be placed there deliberately by the caller, and a cross-site page has no way to make the browser add it. Both endpoints are exempt, and the reason is the same sentence in both rows. Notice what the reason is **not**. It is not that these callers are machines, not that they are trusted partners, and not that the signature *is* an anti-forgery value — the signature authenticates the caller, which is a different job from evidencing intent. The exemption rests entirely on who attaches the credential. ## The test is 'ambient', not 'in a header' The heuristic most candidates reach for — *a credential in a header is safe, a credential in a cookie is not* — is close enough to be dangerous: - **Set by the calling program per request** — not ambient; a cross-site page cannot make the browser add it. - **Resent by the user agent without the page asking** — ambient, whatever header it travels in. - **Stored in the cookie jar** — ambient by construction, which is why every staff-facing route is protected. RFC 7617 Section 2.2 is the case to know. Once a client has been challenged for a protection space it may **preemptively** attach the `Authorization` header to requests for resources it judges to be in that space, matched by path prefix, without waiting for another challenge. A browser that has answered a `Basic` challenge does exactly that. So an endpoint that natively challenges the browser with `WWW-Authenticate` is in the same position as a cookie-authenticated one: the credential arrives on requests the user never initiated, and the endpoint does not get the carve-out. ## What keeps the carve-out safe The verdict is the easy half. The exemption is a standing statement about the service, and four things keep it true: 1. **Scope it to paths, not to the service.** A matcher naming the two machine routes leaves every other route protected. A global switch — or an exemption on a shared path prefix — silently covers whatever is added next. 2. **Prove there is no cookie path into the route.** The exempted endpoint must reject the session cookie rather than accept it as an alternative, must not fall back to an authenticated browser session when its own credential is missing, and must not be mounted where the browser-facing pipeline also serves it. 3. **Make the list testable.** Enumerate the route table in a test and assert every route is either covered by the check or named in the exemption list with a reason; fail on anything unclassified. 4. **Re-audit on change.** A new caller, a merged route, or a front end pointed at an existing endpoint each invalidate a row. The exemption was true about a service that no longer exists. ## How the carve-out rots The usual sequence is mundane. Someone needs one machine endpoint exempt, finds the global switch first because it is one line, and turns the check off for the whole service; the two staff-facing routes that existed that day are re-covered by hand, and the four added since are not. Or the registry client is retired, a browser page is pointed at its endpoint, and the exemption row is never revisited — the route now accepts a cookie while carrying a written reason saying no browser-attached credential reaches it. Both failures are invisible in testing, because everything a legitimate caller does still works. Nothing catches them except the list, reviewed as an artefact, which is why the reason column matters as much as the verdict column: a row that says only *exempt* tells the next reader nothing they can re-check, while a row that says *no ambient credential; cookie rejected on this route* is a claim someone can go and falsify.