All input parameters of external interfaces MUST be validated restrictively.
Input validation MUST be performed server-side. Client-side validation MAY be implemented but only for usability reasons in addition to server-side validation or to prevent client-side attacks.
Input validation SHOULD be relying on a positive model (whitelisting).
Input validation MUST be performed as strictly as possible in respect of allowed data type, length, and range.
Input validation SHOULD be performed implicitly with data binding (typecasting) where possible.
In order to remove path truncations like “
../../”, directory paths MUST be normalized / before input validation is applied to it[1].Input validation MUST be applied to all types of input parameters (including hidden form fields and cookies).
Validation of application parameters (non-form parameters) SHOULD be performed implicitly via integrity checks or indirection mappings where possible.
HTML input MUST be validated restrictively with a mature HTML sanitizer API.
XML data from untrusted sources (e.g. received by a service) MUST always be validated indirectly (e.g. via bean validation) or directly via an XML Schema. This MUST be done in a restrictive way. Examples:
Numeric instead of a string datatype,
limitations for numeric data types or
restricting allowed characters for a string (e.g. only “a-z” and “A-Z”).
An XML parser that process XML content from untrusted sources (e.g. from an external entity) MUST be hardened to prevent common XML-based attacks:
Set restrictive limits (e.g. in respect of maximal nesting depth or document size),
deactivate processing of external XML entities.
In order to prevent insecure object deserialization, it MUST be ensured that objects received and bound from untrusted sources are not hostile or tempered (e.g. by only binding non-sensitive attributes, perform whitelisting or integrity checks.
[1] Often APIs like getCanonicalPath() exists for this matter.