B.2 - Input Validation
B.2.1 General Requirements
- All untrusted input parameters (e.g. of external interfaces) MUST be validated restrictively where possible.
- Validation policy SHOULD be defined by the data owner.
- Input validation SHOULD be performed as strictly as possible with respect to allowed data type, length, and range. Examples:
- Numeric instead of a String datatype,
- limitations for numeric data types (e.g. range, length),
- only allow lists or enums for a String datatype,
- restricted allowed characters via RegExp for a string (e.g. only
a-z
andA-Z
).
- Input validation SHOULD be using a positive validation model (whitelisting).
- In order to prevent deserialization attacks, untrusted data SHOULD generally not be deserialized.
- Data with high integrity protection requirements SHOULD be validated using cryptographic integrity checks (see ).
- JSON or XML data from untrusted sources (e.g. received by a service) MUST be validated using schema validation (e.g. OpenAPI, XML, or JSON schema) or bean validation. Schemas SHOULD be restrrictive where possible (e.g. avoid using unrestricted String datatypes) (see B.12 - API Security).
- An XML parser that processes 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. with respect to 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, performing whitelisting or integrity checks.
B.2.2 Additional Requirements for Web-based UIs
- Security-relevant input validation MUST be performed on the 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 MUST be applied to all types of untrusted input parameters (including hidden form fields and HTTP headers such as cookies).
- Validation of user input SHOULD be performed implicitly with data binding (typecasting) where possible.
- Validation of non-editable application parameters (no user input) SHOULD be performed implicitly via integrity checks or indirection mappings where possible.
- In order to remove path truncations like
../../
, directory paths MUST be normalized before input validation is applied to them 1. This MAY be done implicitly by using a secure API that removes such truncations automatically. - HTML input MUST be validated restrictively with a mature HTML sanitizer API.
- Redirects MUST be checked against a list of allowed URLs or hosts.
-
Often APIs like
getCanonicalPath()
exists for this matter. ↩