Validate at the Boundary, Then Trust Inside

The form in the browser disables the submit button when the email is empty. The API stores whatever string arrives, because "the form already checked." A script posts an empty email. A later report crashes on a missing value the database allowed. The check lived in the one place a caller can bypass.

Validate at each trust boundary, once, completely. The handler turns bytes into a value that satisfies the rules, or it returns an error and stops. Code inside the boundary receives that value and does not re-parse the raw string. Repeating the same checks everywhere means some path will forget one. Doing them nowhere means the database becomes the accidental validator, with a worse error.

What to check before you accept the input

• Presence of required fields, and absence of fields the caller must not set, such as a price or a role.
• Type and range: a quantity is an integer within the bounds you sell, not merely a number.
• Allowed values: a status is one of the statuses you defined, not any string.
• Size: a comment, a file, and a list have ceilings. An unbounded list is a resource problem as well as a data problem.
• References: the foreign key exists and the caller is allowed to use it. Format is not permission.
• The error names the field, as in Make API Errors a Contract.

Client validation can run the same rules so a person gets a fast response. It is not the boundary. The OWASP Input Validation Cheat Sheet treats server-side validation as the control that remains when the client is untrusted, which it always is.

Illustrative scenario

This scenario is illustrative. An order endpoint accepts SKU, quantity, and warehouse. The handler rejects an unknown SKU, a quantity below one, and a warehouse the caller does not operate. The service method receives three typed values and creates the order. It does not receive the raw JSON. A model that proposes the same three fields is not inside the boundary. Its proposal goes through the same handler. Put AI on the Decision, Not in a Chat Tab is that product shape. The validation rule is the same either way.

Checklist

• Name every entry: HTTP, queue, file, scheduled job, admin script.
• Validate at each entry. Do not assume the previous hop did it, unless that hop is your own code and the value is already typed.
• Keep the rules next to the contract, and test them without the database when you can.
• Reject extra fields that would let a caller set price, owner, or role.
• Return the failing field. Log the rejection without logging secrets inside the payload.
• Run model output through the same validator before it writes.

Questions that usually come next

Is database constraint checking a substitute?

Constraints are the last line, and they are worth having. They are a poor API. A constraint failure is hard for a client to map back to a field, and it happens after you have done other work. Validate first. Keep the constraint so a bug cannot skip the validator.

Should we validate again in the domain model?

Invariants that define the business object belong with the object: an order total matches its lines. Parsing and size limits belong at the edge. If both layers repeat the email regex, one of them will drift.