Input Validation Principles
Validation at Every Boundary Input validation should occur at every trust boundary including HTTP requests, message bus consumers, file parsers, and API endpoints. Validation at boundaries prevents malicious data from entering the system. Schema-based validation using JSON Schema, Protocol Buffers, or Apache Avro provides structured validation with clear contracts. Schemas define expected types, formats, and constraints. Validation should be centralized in framework middleware or shared libraries, ensuring consistent application across all endpoints. Decentralized validation leads to gaps and inconsistencies. Type, Length, Range, and Format Enforcement Type validation ensures that inputs match expected data types. String inputs should not be accepted where integers are expected. Length validation prevents buffer overflows and resource exhaustion. Maximum lengths should be enforced based on business requirements and storage constraints. Range validation ensures that numeric inputs fall within acceptable bounds. Range checks prevent integer overflow and business logic errors. Format validation using regular expressions or parsing libraries ensures that inputs match expected patterns. Email addresses, URLs, and phone numbers should be validated against strict formats. Canonicalization Canonicalization transforms inputs into standard form before validation, preventing bypass through encoding variations. Unicode normalization converts different representations of the same character into single form. Path canonicalization resolves relative paths and symbolic links, preventing directory traversal attacks. Canonical paths should be validated against allowed directories. URL canonicalization handles encoding variations and protocol differences. URLs should be parsed and validated in canonical form. Allow-Lists Over Deny-Lists Allow-list validation explicitly defines acceptable inputs, rejecting everything else. Allow-lists are more secure than deny-lists, which attempt to enumerate all dangerous inputs. Deny-lists are incomplete by nature, as new attack patterns emerge continuously. Allow-lists remain secure as attack patterns evolve. Enumerated types and strict format validation implement allow-list approaches. Only known-good values should be accepted. Rejection Over Coercion Invalid inputs should be rejected with clear error messages rather than silently truncated or coerced. Silent coercion can lead to security vulnerabilities and data corruption. Truncation can bypass validation by removing dangerous characters after validation. Inputs should be rejected if they exceed length limits. Type coercion can lead to unexpected behavior. Strict type checking should be enforced.Output Encoding
Context-Aware Encoding Output encoding must match the destination context including HTML, JavaScript, CSS, URL, or JSON. Each context has different encoding requirements. HTML encoding escapes characters including angle brackets, quotes, and ampersands that have special meaning in HTML. HTML encoding prevents cross-site scripting in HTML content. Attribute encoding differs from element content encoding. Attributes require additional encoding for quotes and spaces. HTML Context Template engines with automatic escaping including React, Vue, and Angular provide context-aware HTML encoding by default. Auto-escaping should be enabled globally. Manual HTML encoding should use framework-provided functions rather than custom implementations. Custom encoding implementations are error-prone. Dangerous sinks including innerHTML should be avoided. DOM manipulation should use safe APIs including textContent and setAttribute. JavaScript Context JavaScript string encoding escapes quotes, backslashes, and control characters. JavaScript encoding prevents script injection in JavaScript strings. Inline event handlers including onclick should be avoided, as they mix HTML and JavaScript contexts. Event handlers should be attached programmatically. eval and Function constructor should never be used with user input. Dynamic code execution enables arbitrary code injection. CSS, URL, and JSON Contexts CSS encoding prevents injection in style attributes and style blocks. CSS encoding escapes characters with special meaning in CSS. URL encoding (percent encoding) escapes special characters in URLs. URL components should be encoded separately (path, query, fragment). JSON encoding uses JSON.stringify or equivalent library functions. Manual JSON encoding is error-prone and vulnerable to injection. Context mixing where single output contains multiple contexts requires careful encoding for each context. Context mixing should be avoided where possible.SQL and Command Injection Prevention
Parameterized Queries Parameterized queries (prepared statements) separate SQL code from data, preventing SQL injection. Parameters are sent separately from query structure. ORMs including Hibernate, Entity Framework, and SQLAlchemy provide parameterized queries by default. ORM usage should be enforced through code review. String concatenation for SQL queries should be prohibited through static analysis. Concatenation enables SQL injection. Stored procedures provide additional layer of abstraction but do not prevent SQL injection if they use dynamic SQL. Stored procedures should use parameterized queries internally. Command Injection Prevention Shell command execution should be avoided entirely where possible. Native libraries and APIs should be used instead of shell commands. When shell execution is unavoidable, argument arrays should be used instead of string commands. Argument arrays prevent shell metacharacter interpretation. Shell quoting is complex and error-prone. Quoting should use language-provided functions rather than manual implementation. Sandboxed execution using containers or restricted shells limits impact of command injection. Sandboxing provides defense-in-depth.File Upload Security
Content Validation MIME type validation checks Content-Type headers, but headers are attacker-controlled. MIME types should be validated but not trusted. File extension validation prevents execution of uploaded scripts. Extensions should be validated against allow-list. Content-based validation examines file contents to verify file type. Magic number validation checks file headers. Image validation should use image processing libraries to parse and re-encode images. Re-encoding removes embedded malicious content. Storage Security Uploaded files should be stored outside web roots, preventing direct execution. Files should be served through download handlers with appropriate Content-Type headers. Virus scanning should be performed on all uploads. Scanning should occur before files are made available. File transcoding converts risky formats to safe formats. PDF transcoding can remove embedded JavaScript. Filename Sanitization Filenames should be sanitized to remove path traversal characters and special characters. Filenames should be validated against allow-list of characters. Generated filenames using UUIDs eliminate filename-based attacks. Original filenames can be stored as metadata.Testing and Validation
Property-Based Testing Property-based testing generates random inputs to test parser robustness. Property tests verify that parsers handle all inputs safely. Fuzzing tools including AFL and libFuzzer generate malformed inputs to find parsing vulnerabilities. Fuzzing should be integrated into CI/CD pipelines. Negative Testing Negative tests verify that invalid inputs are rejected. Negative tests should cover boundary conditions and malicious inputs. Encoding tests verify that dangerous characters are properly encoded. Tests should verify encoding in all supported contexts. Static Analysis Static analysis tools detect dangerous patterns including string concatenation in SQL queries and use of dangerous functions. Static analysis should be enforced in CI/CD pipelines.Conclusion
Input validation and output encoding prevent injection attacks by treating all external data as untrusted and ensuring that data is safe in its destination context. Security engineers implement validation at every boundary and context-aware encoding for all outputs. Success requires understanding the difference between validation and encoding, using framework-provided functions, and comprehensive testing. Organizations that invest in input validation and output encoding fundamentals eliminate entire classes of injection vulnerabilities.References
- OWASP Input Validation Cheat Sheet
- OWASP XSS Prevention Cheat Sheet
- OWASP SQL Injection Prevention Cheat Sheet
- OWASP Command Injection Defense
- Unicode Security Considerations