A Hidden Form Field Is Not a Trust Boundary

A hidden form field can remember which item a person is editing without asking them to type its identifier. That is useful context. It is not proof that the person is allowed to edit the item.

Consider an application that shows an editable draft. The page displays the draft title and includes its identifier in the form:

<form action="/drafts/update" method="post">
  <p>Editing draft: Garden notes</p>
  <input type="hidden" name="draft_id" value="draft-42">
  <label for="title">Title</label>
  <input id="title" name="title" value="Garden notes" required>
  <button type="submit">Save draft</button>
</form>

When the form is submitted normally, the named hidden control contributes its value along with the title. The control is not displayed as an editable field, but its value is present in the page and can be inspected or changed with browser developer tools. Someone can also construct a request without using this form at all. The server must treat the identifier as a request to locate a draft, not as evidence of permission.

A sound server-side sequence starts by establishing the requester through the application’s authentication mechanism. Then validate that the submitted identifier has an acceptable shape and use it to locate the requested draft. Before changing anything, check whether that requester is authorized to edit that particular draft. If the identifier is missing, invalid, unknown, or not authorized for the action, refuse the update according to the application’s error policy.

Validate the new title separately. An authorized editor can still submit an empty or oversized title, and browser-side requirements are not a substitute for server checks. If the draft changed after the page was loaded, the application may also need a version check so that an old form does not silently overwrite a newer edit. A version value sent by the client is still a claim to compare against server state, not a fact to accept blindly.

A difficult-to-guess identifier can reduce casual discovery, but it does not replace the object-level permission check. Likewise, moving the identifier into a URL or a different form field changes where it appears, not who controls the request.

Hidden fields can legitimately carry other data, including a cross-site request forgery token. Such a token’s protection comes from how it is generated and verified, not from the field being invisible. It also does not replace authorization for the draft.

Keep the hidden identifier if it makes the workflow clearer. Just make the decision on the server: identify the requester, validate the submitted data, and check permission for the specific operation.