Incomplete mediation occurs when a system fails to validate all input values against every constraint before acting on them.
Any input from the user or through the network should be considered invalid and untrusted by default. Exhaustive checks should be performed on all input values to ensure they meet the expected constraints.
For example:
http://www.abc.com/subpage/userinput.asp?par1=(808)555-1212&par2=2017Jan24par2 is left unvalidated against constraints it should satisfy, e.g.:
1800Jan01, outside the acceptable range.2000Feb30, a non-existent date.2048Min32, an undefined unit.1Aardvark2Many, not a date at all.
Client-side fixes, e.g. validating input before submission or restricting choices to a drop-down menu, remain vulnerable.
The results of client-side verification are exposed in the URL. A malicious user can bypass the client entirely, edit the URL fields directly, and send the request straight to the server. The server cannot tell whether a URL came from its own client’s browser or from a modified request.
Trust Boundary
The trust boundary is the server, not the browser. Anything on the client side, form scripts, dropdown constraints, JavaScript checks, is under the attacker’s control and can be bypassed or edited before the request reaches the server.
Validation must be re-done server-side regardless of what the client already checked. Client-side validation is done only for good user experience.
Server-Side Validation
Complete mediation means every input is checked against every constraint on every request, not just at the point of entry:
- Type
does the value match the expected data type. - Range
does the value fall within acceptable bounds. - Format
does the value match the expected structure (e.g. a real calendar date). - Allowlist over denylist
reject anything that isn’t explicitly permitted, rather than trying to enumerate every bad input. - Re-check on every request
a value validated once (e.g. at login) can’t be trusted as still valid later; state can change or the request can be forged.