Why is a server-side write function that a route exposes as a POST target treated as a public endpoint?

## The mechanism forces the conclusion To make a form submit reach server code, the framework has to give that code an address. There is no other way: the browser needs a URL to put in `action`. Once that address exists, it behaves like every other URL in the system — a request to it is just bytes with a method, a path, headers, cookies and a body. Anything able to send those bytes can invoke the handler: a script in a terminal, a rewritten page in a developer console, a crawler that found the address in the markup, a replayed request from a proxy log. What does *not* travel with that request is everything the rendering pass knew. The server decided, while producing the page, that this user was an administrator and therefore rendered a delete button. That decision lived in a render that has already finished. The next request is a new one, and it carries no memory of it. ## What must live inside the handler Three checks, none of which the UI can perform on the handler's behalf: 1. **Identity.** Who is this? Read it from the request itself — the session the cookie identifies — not from anything the client submitted. A user id in a hidden field is a claim, not an identity. 2. **Permission on this object.** Not "may this role delete things" but "may *this* caller delete *this* record". Identifiers arrive in the body and can be changed freely, so the check has to be scoped to the specific target. 3. **The shape of the input.** Fields arrive as text. Presence, type, range, length and the set of allowed values are all still open questions when the handler begins, and extra fields nobody expected may be present. The useful mental test: **assume the form does not exist and the caller composed the request by hand.** Everything that still holds is a control; everything that stops holding was scenery. ## Why hiding the control is not a control | What the page does | What it changes for a direct request | |---|---| | Renders the button only for admins | nothing — the address is unchanged | | Disables the button while a write is pending | nothing — no button is involved | | Omits the form entirely for read-only users | nothing — the handler still answers | | Validates the field before submitting | nothing — the body is whatever the caller sent | Every row is worth doing for the people using your UI. Not one of them survives a request that did not come from your UI. ## What an origin check is for Most frameworks compare the submitting origin against the app's own and reject a mismatch. That addresses one specific problem: a page on someone else's site causing the user's browser to submit to your handler with the user's cookies attached. It is genuinely useful, and it is a **floor, not a fence**: - It says nothing about **who** is calling — a legitimately signed-in user of your own app passes it while doing something they should not be allowed to do. - It says nothing about **what** was submitted — the body is still unvalidated. - It constrains **browsers**, which refuse to let a page forge the header. A client that is not a browser sets or omits headers as it pleases, so for a request carrying a stolen or borrowed credential the check is not an obstacle. - It needs configuration when legitimate traffic arrives through a different host name than the app believes it is served from, which is a common source of "it works locally and fails behind the proxy". So treat it as one layer that removes a class of attack, sitting beneath the checks that actually decide the outcome. ## The consequence for how you write the handler A handler written this way opens the same way every time: establish the caller from the request, load the target object, check the caller against that object, parse and constrain the input, and only then do the work. The ordering matters — loading the object before checking permission is fine, but returning anything about it before the check leaks existence. One more consequence is worth naming: since the checks are in the handler, the UI can be as permissive as it likes without becoming a security problem, and the handler's rejection has to be renderable. A permission failure is an outcome the route must be able to show, not an assertion that crashes the process. ## What this shares with any other endpoint None of this is special to route-handled writes. It is the ordinary discipline of exposing an HTTP endpoint, which is exactly the point: the convenience of declaring the write next to the component makes it easy to forget that an endpoint is what you created. The colocation is an authoring convenience, not a privacy boundary.