A clinic booking site authenticates owners with a session cookie; why does a form submitted from an unrelated page arrive authenticated?
answer
- who applies the credential?
- destination, not source
- ambient authority
- cookie chosen by where it is going
- only the intent is forged
basics
~20 sA browser attaches a stored cookie according to where a request is going, not according to which document caused it. The hostile page's form is addressed to the clinic, so the clinic's session cookie rides along and the request authenticates.
solid answer
~50 sThe credential is applied by the user agent, not by the page. When the owner signed in, the clinic stored a session cookie; from then on the browser's rule for putting a `Cookie` request header field on an outgoing request is a **destination** rule — does this cookie's scope match the host and path this request is addressed to. The rule does not ask which document initiated the request or who wrote it. So a form on a page the clinic never served produces a request that carries a real, live session. That is **ambient authority**, and it is the whole of cross-site request forgery: the session is genuine, the credential is genuine, the request is well-formed, and only the intent behind it is forged. The attacker never reads the cookie and never needs to.
code
http · 8 linesPOST /appointments/8412/reschedule HTTP/1.1
Host: booking.vetclinic.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Origin: https://pet-deals.example
Cookie: session=8f2c1ab94d7e
slot=2026-10-02T09%3A00go deeper
Be able to say in one sentence that the browser attaches the session cookie because of where the request is going, so a request caused by somebody else's page still arrives authenticated.
Explain ambient authority as the mechanism: the credential is applied by the user agent rather than by the initiating code, so authentication tells the server who, never what caused it.
Show that you judge every proposed defence by whether it removes ambient authority or merely narrows the window in which it can be abused, and that you can say which conditions the attack actually needs.
Frame it as an authority-model problem: credentials the platform applies automatically are convenient and unattributable, and any estate that authenticates by cookie inherits this by default rather than by choice.
## What "ambient authority" means When an owner signs in to the clinic's booking site, the server returns a `Set-Cookie` response header field and the browser stores that cookie against the site that issued it. From then on, for every request the browser is about to send, it decides by itself whether that cookie belongs on the request. The decision is made from **where the request is going** — the host and path it is addressed to, matched against the scope the cookie was stored with. The decision does not consider which document asked for the request, who wrote that document, or whether a person clicked anything. That property is called **ambient authority**: the credential is in the air around every request headed for the clinic, applied by the user agent rather than by the code that initiated it. A page's own script never has to possess the credential to benefit from it — and a page with no script at all benefits from it just as much. This one property is the whole vulnerability. The shape of the forged request, the bait that delivers it and the check that eventually rejects it are all detail hung off it. ## What the clinic's server actually receives An owner is signed in to the clinic in one tab. In another tab they open an unrelated page carrying a form addressed at the clinic's reschedule endpoint. When that form submits, the browser builds an ordinary request: the method the form declares, a body in a form encoding, and a `Cookie` request header field carrying the clinic's session cookie — because the request is going to the clinic. At the server, the session lookup succeeds. The account is real, the session is live, the authorisation check passes (this owner genuinely may reschedule their own appointment), and the audit trail records the owner. Every one of those statements is true. The request is not a replay, not a spoof and not a stolen credential; it is the owner's own browser, acting on the owner's own session, on behalf of somebody else's page. ## What is forged and what is not | Part of the request | Genuine or forged | |---|---| | The session cookie | Genuine — the clinic issued it to this owner | | The identity behind it | Genuine — it really is that owner's browser | | The HTTP request itself | Genuine — correct method, correct fields, well-formed body | | The authorisation decision | Correct — the owner may do this to their own appointment | | The intent | **Forged** — the owner never asked for it | An interviewer is listening for that last row. A candidate who answers "the attacker stole the session" has described a different attack class and has not understood this one. ## Why "the attacker cannot read the cookie" is not a defence Three true statements get offered as defences here and none of them is one: - **The hostile page cannot read the clinic's cookie.** True, and irrelevant: it does not have to. The browser attaches the cookie for it. - **The hostile page cannot read the clinic's response.** True, and irrelevant: the appointment was already rescheduled when the server handled the request. The attack is write-only. - **The owner never typed anything into the hostile page.** True, and irrelevant: markup can emit a request with no credential entry and, for some request shapes, with no interaction at all. ## The conditions the attack needs 1. A live session cookie for the clinic sitting in that browser profile — not an open clinic tab, just an unexpired session. 2. The owner's browser loading the hostile document, or being induced to act on it. 3. An endpoint that acts on a well-formed authenticated request without asking anything about where the request came from. Remove any one and the forgery fails. The first is outside your control and the second is outside your control; every real defence therefore attacks the third. ## Where provenance actually lives It is worth being precise about the limit of the claim. The server is not blind: a browser does attach provenance information to a cross-site submission, and a server can also hand out a value that only a document it served could echo back. Both of those are how the defences work, and both belong to the defence material rather than here. What belongs here is the starting position they all begin from — that authentication alone answers *who* the request came from and says nothing at all about *what caused it*.
- Does the owner need the clinic's site open in another tab for this to work?No. All that is needed is an unexpired session cookie for the clinic sitting in that browser profile. The browser attaches it because of where the request is addressed, not because a clinic document is open somewhere. This is why "I always close the tab" is not protection.
- The clinic's session cookie is marked unreadable to script. Does that change the attack?No. Keeping a cookie out of reach of page script addresses a different attack, one where injected code exfiltrates the value. This attack never reads the value; it relies on the browser attaching it. The two defences answer different threats and neither substitutes for the other.
- If the request is genuine in every respect, what can the server look at to tell the two apart?Something the request carries about its provenance rather than about its credential: information the browser adds about the document that caused the request, or a value the server issued to a document it served and expects back. Which of those to use, and what each one costs, is the subject of the defence material.
A doorman who clips the clinic's membership card to anything addressed to the clinic, without ever asking who wrote the letter.
saying these in an interview costs you the question
- Says the attacker stole or read the owner's session cookie
- Thinks the same-origin policy stops the request being sent at all
- Believes the attacker needs the owner's password or a phished credential
- Assumes the attack fails because the response is never readable
- Calls it a browser defect rather than the cookie model working as specified