TrustClientInput [anti-pattern] v0.1.0

Relying on JavaScript validation, hidden form fields, disabled buttons, or HTTP headers set by the user agent to enforce a security or correctness invariant. Every byte the client sends is attacker-controlled.

Label

Trusting the client to enforce validation, authz, or business rules

Why Bad

Anyone can replay, replace, or fabricate the request with curl, Burp, Postman, or a custom HTTP client. Validation that runs only in the browser is purely a UX hint. 'isAdmin' fields in JWT claims the client signs, role names in form posts, prices in shopping-cart hidden inputs — all routinely tampered. The result is auth bypass, IDOR, price manipulation, or stored XSS depending on the field.

Instead Do

    Treat the network boundary as the trust boundary. At every controller:

      1. Parse and canonicalise the request.
      2. Validate against a server-side schema (allow-list).
      3. Re-derive any security-relevant fact from the server (current
         user, role, price, inventory) — never read it from the request.
      4. Authorise: does THIS user have permission to do THIS thing on
         THIS resource? Use the server's view of identity.

    Client-side validation is fine as UX polish — but everything must be
    re-checked server-side or it does not exist as a control.
  

TrustClientInput [anti-pattern] v0.1.0

Relying on JavaScript validation, hidden form fields, disabled buttons, or HTTP headers set by the user agent to enforce a security or correctness invariant. Every byte the client sends is attacker-controlled.

Label

Trusting the client to enforce validation, authz, or business rules

Why Bad

Anyone can replay, replace, or fabricate the request with curl, Burp, Postman, or a custom HTTP client. Validation that runs only in the browser is purely a UX hint. 'isAdmin' fields in JWT claims the client signs, role names in form posts, prices in shopping-cart hidden inputs — all routinely tampered. The result is auth bypass, IDOR, price manipulation, or stored XSS depending on the field.

Instead Do

    Treat the network boundary as the trust boundary. At every controller:

      1. Parse and canonicalise the request.
      2. Validate against a server-side schema (allow-list).
      3. Re-derive any security-relevant fact from the server (current
         user, role, price, inventory) — never read it from the request.
      4. Authorise: does THIS user have permission to do THIS thing on
         THIS resource? Use the server's view of identity.

    Client-side validation is fine as UX polish — but everything must be
    re-checked server-side or it does not exist as a control.
  

Label

Trusting the client to enforce validation, authz, or business rules

Why Bad

Anyone can replay, replace, or fabricate the request with curl, Burp, Postman, or a custom HTTP client. Validation that runs only in the browser is purely a UX hint. 'isAdmin' fields in JWT claims the client signs, role names in form posts, prices in shopping-cart hidden inputs — all routinely tampered. The result is auth bypass, IDOR, price manipulation, or stored XSS depending on the field.

Instead Do

    Treat the network boundary as the trust boundary. At every controller:

      1. Parse and canonicalise the request.
      2. Validate against a server-side schema (allow-list).
      3. Re-derive any security-relevant fact from the server (current
         user, role, price, inventory) — never read it from the request.
      4. Authorise: does THIS user have permission to do THIS thing on
         THIS resource? Use the server's view of identity.

    Client-side validation is fine as UX polish — but everything must be
    re-checked server-side or it does not exist as a control.