ASVS 5.0 V2.2.2 requires that input validation is enforced at a trusted service layer. Client side validation is welcome for usability, but it must never be the security control. This is a Level 1 requirement.
Why it matters
The browser is the attacker's tool. Anyone can open developer tools, use curl, replay a request through a proxy, or write a script that never loads your page. If the only check is a form attribute or a JavaScript function, a single direct request skips it.
Mobile apps and single page apps are in the same position. The app is code on the user's device, and the API behind it receives whatever anyone chooses to send.
How to implement it
Treat the server as the only authority. The client can show helpful errors early, but every API handler validates again, without assuming the client did anything.
A good layout has three layers:
- The edge, such as an API gateway, enforces size limits, content types and authentication.
- The service layer validates structure and values with a schema, then applies business rules.
- The data layer enforces constraints that must always hold, such as not null, unique and foreign keys.
Share the schema between client and server when your stack allows it, for example one JSON Schema file used by both. That keeps messages consistent without trusting the client.
# Flask handler: the check lives here, whatever the form did
@app.post("/profile")
def update_profile():
data = ProfileUpdate.model_validate(request.get_json(force=True))
...
Make sure every entry point goes through the same validation: REST, GraphQL, WebSocket messages, file uploads, and background job inputs.
How to test it
Take a working request from the UI and replay it with curl or a proxy after changing a value to break a client rule: a longer string, a negative number, a missing field, a changed hidden field. The server must reject it. Then turn off JavaScript, or call the endpoint directly, and repeat for each state changing endpoint. Automated API scans do this at scale.
Where server side validation tends to be missed
Single page applications and mobile apps make it tempting to put the rules in the client, because that is where the form lives. The API tells a different story. Keep a list of every route that changes state, and for each one write down the rule that protects it and where it runs. Gaps show up quickly when you do it that way.
Mass assignment and hidden fields
A form shows three fields, but the handler binds the whole request body to a model. An attacker adds isAdmin or price and it sticks. Declare the allowed fields explicitly and reject the rest, using a schema with unknown keys forbidden. The same goes for hidden inputs and values stored in the page: treat them as user input.
Direct object references
Validation includes checking that the caller may use the identifier they supplied. A well formed order number that belongs to another customer is valid input and an invalid request. Combine format checks with an ownership check on every lookup.
Keep client checks, with the right label
Do not delete client side validation. It saves round trips and makes forms pleasant. Just describe it in your documentation as a usability feature, and never mark a requirement as met because of it.
Common mistakes
- Relying on
maxlength,requiredorpatternattributes in HTML. - Trusting hidden fields, such as a price or user id, because the form set them.
- Validating in the gateway but letting internal services accept raw input from other callers.
- Validating one entry point (REST) but not the alternative (GraphQL or WebSocket).
Try it yourself
Run a web scan against a test target to see how automated tools replay requests with changed values.
Click through it at your own pace, or open it full screen.
Quick check
If we validate in the browser and the gateway, is the service safe to skip?
No. Services can be reached by other callers and future routes. Each service validates its own input.
Should client validation be removed?
No. It improves usability. It just must not be counted as protection.
