Never trust submitted input

The browser interface is not a security boundary. The server receives a request, not proof that someone used your form as intended.

A client can:

• omit required fields
• repeat a field several times
• add fields that do not exist in the page
• change hidden and disabled values
• skip browser validation
• send a different content type
• upload arbitrary bytes under a familiar filename

Start each endpoint with an explicit contract. For a profile update, it might accept displayName as a string of 1–80 characters and timezone as one value from a known list. Everything else is ignored or rejected.

Validate in layers:

1. Check that the request body is small enough to parse safely.
2. Accept only the expected content type.
3. Parse with a maintained parser.
4. Check required fields and data types.
5. Check lengths, ranges, and allowed values.
6. Check relationships and business rules.
7. Check that the authenticated user may perform the operation.

Syntax and meaning are different. 2026-07-30 may be a valid date string but still be unavailable for a booking. A numeric productId may exist but belong to another account.

Validation also does not replace safe output and database APIs. Escape untrusted text for the HTML context where it appears. Use parameterized database queries rather than joining input into SQL.

Do not accept a trusted value from the form when the server already knows it. Read the current user from the authenticated session. Read an item’s price from the database. Treat a submitted price or owner ID as a claim to verify, not a command.

Return useful field errors for ordinary mistakes. Log repeated or structurally impossible failures without recording secrets.

Take one endpoint and write its accepted fields, types, limits, allowed values, and authorization rule. Then send one request that violates each rule.