How can organisations prevent external control of critical state data?

Why critical state must stay server-side

External control of critical state happens when the browser or client can alter values the server later trusts as authoritative. The safest design is to keep the system of record on the server and treat client-supplied values only as hints to be checked, not facts to be accepted. That matters for roles, pricing, workflow stage, entitlement flags, and any value that changes behaviour.

If the client can decide its own state, the application has effectively delegated business logic and security decisions to an untrusted endpoint. Hidden fields, cookies, URL parameters, local storage, and token payloads are all common places where this trust breaks down. The fix is not just “hide the value”, it is to ensure the server owns the canonical state and re-evaluates it on each request.

When state must round-trip through the client, CWE Top 25 Guide is useful for mapping the underlying weakness class, especially cases like externally controlled configuration, missing authorization, and insufficient validation of returned data.

How to prevent tampering with hidden fields, cookies, and tokens

The practical control pattern is simple: sign or otherwise integrity-protect any state that must be returned by the client, then verify it before use. If the value cannot be trusted, do not use it to grant privilege, alter workflow, or change security posture. Recompute sensitive decisions on the server instead of preserving them in a mutable client field.

That means treating the client as an untrusted transport layer. A role claim in a cookie is not a role assignment unless the server can verify the issuer, integrity, freshness, and context of that value. The same applies to checkout totals, step numbers in a process, feature entitlements, approval state, and object ownership markers.

Web Application Attacks Guide is a strong companion when the issue is parameter tampering, hidden-field manipulation, or other request-side abuse patterns that let attackers rewrite state in transit.

For API-backed systems, validate the transition itself, not just the value supplied with it. That is the point where OWASP API Security Top 10 becomes especially relevant, because broken authorization and unsafe state-changing flows often expose the same trust failure through a different interface.

What strong state validation looks like in practice

Good validation compares the proposed transition against server-side rules, current object state, and the authenticated identity making the request. A request to move an order, approve a workflow, or change a payment amount should succeed only if the server sees that transition as valid for that user, that object, and that moment. If the transition is invalid, the server should reject it even when the client presents a plausible value.

State validation also needs replay resistance and context binding where the value has security impact. A token or cookie that was valid earlier should not remain useful after the relevant session, transaction, or privilege has changed. The more sensitive the state, the less the server should rely on client persistence and the more it should prefer one-time or server-issued references.

CISA cyber threat advisories can help teams track how attackers operationalise tampering, replay, and session abuse when defending real systems, especially where state integrity failures lead to privilege changes or fraud.

Risk and Threat Considerations

When critical state is client-controlled, attackers usually do not need to “break” the application, they only need to change the value the application already trusts. That creates direct exposure to privilege escalation, fraud, workflow abuse, and unauthorised access, especially when the state is embedded in hidden fields, client-side storage, or unsigned cookies.

Failure mechanism: The server accepts a client-supplied value as authoritative, so an attacker can modify state, replay an old value, or swap one object reference for another and still pass the application’s decision logic.

Impact: A minor input-handling flaw can become a security decision flaw, allowing attackers to change roles, bypass approvals, manipulate transactions, or force the application to process an invalid state transition.

Practitioner Guidance

What to verify: Confirm that every security-relevant decision is derived from server-side session, object, or policy state, not from a client-returned field. If the client must send back a value, verify both integrity and freshness before the server consumes it.

Decision rule: If the value affects authorisation, pricing, approval, ownership, or workflow progression, treat it as server-owned state and reject any design that depends on the browser to preserve it accurately.

Common mistake: Teams often protect the transport but not the trust model. HTTPS helps confidentiality in transit, but it does not stop a user from editing their own request, so integrity checks and server-side validation still need to be explicit.

Practitioner takeaway: The safe pattern is to minimise what the client can assert, and make the server re-decide anything that could change access, privilege, or business outcome.

Related resources from NHI Mgmt Group

• What causes external control of critical state data?
• How do developers prevent external control of critical state data?
• How can organisations prevent files or directories being accessible to external parties?
• External Control of Critical State Data