Secure Input Validation Best Practices

Input Validation Guidelines

• Input validation should be conducted on a trusted system (server-side) to prevent client-side manipulation.
• All data sources should be identified and classified into trusted and untrusted sources.
• Data from untrusted sources (databases, file streams, etc.) should be validated to ensure security.
• A centralized input validation routine should be used for the whole application to maintain consistency.
• Character sets (e.g. UTF-8) should be specified for all input sources to ensure canonicalization.
• Input should be encoded to a common character set before validation to prevent encoding attacks.
• All validation failures should result in input rejection to prevent malicious data from entering the system.
• If the system supports UTF-8 extended character sets, validation should occur after UTF-8 decoding is completed.
• All client-provided data should be validated before processing to prevent attacks.
• Protocol header values in both requests and responses should only contain ASCII characters to prevent header injection attacks.
• Data from redirects should be validated to prevent redirection attacks.
• Validation should focus on expected data types using an "allow" list rather than a "deny" list to prevent unexpected data types from entering the system.
• Data range and length should be validated to prevent buffer overflow attacks.
• If potentially hazardous input must be allowed, additional controls should be implemented to mitigate risks.
• Extra discrete checks should be used if the standard validation routine cannot address some inputs.
• Canonicalization should be used to address obfuscation attacks that use non-standard encoding techniques.