A booking form's server-issued anti-forgery token can ride in a hidden field or an author-set request header - what does each carriage assume?

## Two carriages, one check The check never changes: read the value the request supplied, look up the value stored against the session, compare them in constant time, refuse on a mismatch. What changes is **where the request carries the value**, and there are two places worth using. - **A hidden input in the form body.** The server writes the value into the markup when it renders the page, and the browser submits it along with the rest of the fields. - **An author-defined request header field.** Code composing the request reads the value from somewhere in the page and sets a header field on the request it issues. The field name is the application's own choice; nothing about it is registered or standard. ## What a document from another site can emit This is the asymmetry the header carriage exploits. A hostile document, with no script at all, can cause a form submission to your site. It controls the method, the action, every field name and every field value, and it can use any of the three encodings a form element is able to produce: `application/x-www-form-urlencoded`, `multipart/form-data` or `text/plain`. What it cannot control is the *value* of your session-bound token, because it cannot read your page. Header fields are different in kind. A form submission, an image load, a frame load - the things a hostile document can emit without script - carry only the header fields the **user agent** itself decides to attach. There is no markup that adds an author-defined one. Script can ask for one, but when script on another origin asks to add an author-defined header field to a request aimed at your site, the browser first checks with your server in a separate exchange, and your server has no reason to permit it. That gives the header carriage a second, independent property: **a request that merely arrives carrying the header at all was composed by code the browser was willing to let compose it.** The value still does the real work, but the carriage corroborates it. ## What each carriage assumes | | hidden field in the body | author-defined request header | |---|---|---| | who puts it there | the server, when it renders the page | code in the page, when it composes the request | | works with no script | yes - this is the whole point of it | no | | what a cross-site document can produce | the field name and a guessed value | not the header field at all | | what the server reads it from | the parsed request body | a header field on the request | | extra evidence beyond the value | none | presence of the header is itself provenance | A server-rendered booking flow - pick a room, pick a slot, confirm - is the hidden field's natural home, because every step is a form the server rendered anyway. A step submitted by code that composed the request itself is the header's natural home, because that code can set a header and a form cannot. ## Failure modes worth naming - **Putting the value in the query string.** It is neither of these two carriages. A URL travels into access logs, into browsing history, into anything a user copies and sends to a colleague, and it survives long after the session does. - **Treating the header name as the security property.** Any name works. What matters is that a header field had to be set by code at all; a clever name adds nothing, and a predictable one costs nothing. - **Letting a page that carries the value be stored by a shared cache.** The markup contains a value bound to one session; a cache that hands the same bytes to a different user has handed out that session's value. - **Assuming the header carriage removes the need for stored state.** It does not. The check is still submitted-versus-stored. Replacing the stored copy with a value echoed back out of a cookie is a different scheme with different assumptions, not a variation on this one. ## The judgment Prefer the hidden field where the server renders the form, because it depends on nothing but markup the server already emits. Prefer the header where code composes the request anyway, because the carriage itself tightens the check. Supporting both at once is normal: the server looks in the header first, falls back to the body field, and compares whichever it found against the same stored value.