Input Validation & Output Encoding

​

Input Validation vs Output Encoding

​

Input Validation Principles

​

Validation at Every Boundary

• Schema-based validation: Use JSON Schema, Protocol Buffers, or Apache Avro for structured validation with clear contracts
• Centralized validation: Implement validation in framework middleware or shared libraries to ensure consistent application across all endpoints
• Defense in depth: Validate at multiple layers (client, API gateway, application, database) rather than relying on a single validation point

// Example: Zod schema validation in TypeScript
import { z } from "zod";

const UserSchema = z.object({
  email: z.string().email().max(254),
  age: z.number().int().min(0).max(150),
  role: z.enum(["user", "admin", "moderator"]),
});

// Validation throws on invalid input
const user = UserSchema.parse(untrustedInput);

​

Type, Length, Range, and Format Enforcement

• Type validation: Ensure inputs match expected data types—string inputs should not be accepted where integers are expected
• Length validation: Enforce maximum lengths based on business requirements and storage constraints to prevent buffer overflows and resource exhaustion
• Range validation: Ensure numeric inputs fall within acceptable bounds to prevent integer overflow and business logic errors
• Format validation: Use regular expressions or parsing libraries (see OWASP Validation Regex Repository) to ensure inputs match expected patterns

​

Canonicalization

• Unicode normalization: Convert different representations of the same character into single form using Unicode Normalization Forms (NFC recommended)
• Path canonicalization: Resolve relative paths (../) and symbolic links to prevent directory traversal attacks (CWE-22)
• URL canonicalization: Parse and validate URLs in canonical form, handling encoding variations and protocol differences

​

Allow-Lists Over Deny-Lists

​

Rejection Over Coercion

• No silent truncation: Truncation can bypass validation by removing dangerous characters after validation—reject inputs exceeding length limits
• No type coercion: Implicit type conversion can lead to unexpected behavior—enforce strict type checking
• Clear error messages: Provide actionable feedback without revealing system internals

​

Output Encoding

​

Context-Aware Encoding

​

HTML Context

• Auto-escaping frameworks: React, Vue, and Angular provide context-aware HTML encoding by default—enable auto-escaping globally
• Template engines: Use Jinja2 (Python), Thymeleaf (Java), or Razor (.NET) with auto-escaping enabled
• Avoid dangerous sinks: Never use innerHTML, document.write(), or outerHTML with untrusted data—use textContent and setAttribute instead

// UNSAFE: XSS vulnerability
element.innerHTML = userInput;

// SAFE: Automatic encoding
element.textContent = userInput;

// SAFE: React auto-escapes by default
return <div>{userInput}</div>;

​

JavaScript Context

• Escape special characters: Encode quotes, backslashes, and control characters in JavaScript strings
• Avoid inline handlers: Never use onclick, onerror, or other inline event handlers with user data—attach event handlers programmatically
• Never use eval(): The eval() function and Function constructor should never process user input—they enable arbitrary code execution (CWE-95)

​

CSS, URL, and JSON Contexts

• CSS encoding: Escape non-alphanumeric characters in style attributes and blocks to prevent CSS injection
• URL encoding: Use encodeURIComponent() for query parameters and encodeURI() for full URLs—encode path, query, and fragment separately
• JSON encoding: Always use JSON.stringify() or equivalent library functions—manual JSON construction is error-prone
• Avoid context mixing: When output spans multiple contexts, encode for each context separately

​

SQL and Command Injection Prevention

​

Parameterized Queries

• Use ORMs: Hibernate (Java), Entity Framework (.NET), SQLAlchemy (Python), and Prisma (Node.js) provide parameterized queries by default
• Prohibit concatenation: Use static analysis tools like Semgrep or SonarQube to detect string concatenation in SQL queries
• Stored procedures: Use parameterized queries within stored procedures—stored procedures alone do not prevent SQL injection if they use dynamic SQL

# UNSAFE: SQL injection vulnerability
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# SAFE: Parameterized query
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

​

Command Injection Prevention

• Use native libraries: Replace shell commands with language-native APIs (e.g., use Python’s os.makedirs() instead of os.system("mkdir -p ..."))
• Use argument arrays: When shell execution is unavoidable, pass arguments as arrays to prevent metacharacter interpretation
• Never use shell=True: In Python’s subprocess, always use shell=False with argument lists
• Sandbox execution: Use containers, seccomp, or restricted shells to limit blast radius

# UNSAFE: Command injection vulnerability
os.system(f"convert {user_filename} output.png")

# SAFE: Argument array prevents injection
subprocess.run(["convert", user_filename, "output.png"], shell=False)

​

File Upload Security

​

Content Validation

• Multi-layer validation: Combine extension, magic number, and content validation for defense in depth
• Image re-encoding: Use ImageMagick, Sharp, or Pillow to parse and re-encode images, removing embedded malicious content
• Document sanitization: Use Apache PDFBox or similar libraries to remove JavaScript from PDFs

​

Storage Security

• Store outside web root: Uploaded files should never be directly accessible—serve through download handlers with explicit Content-Type and Content-Disposition headers
• Virus scanning: Integrate ClamAV or cloud-based scanning before files are made available
• Separate storage domain: Serve user content from a separate domain to prevent cookie theft via XSS

​

Filename Sanitization

• Generate new filenames: Use UUIDs or hashes to eliminate filename-based attacks—store original filenames as metadata
• Remove path characters: Strip ../, ..\\, and null bytes to prevent path traversal (CWE-22)
• Allow-list characters: Accept only alphanumeric characters, hyphens, and underscores in filenames

​

Testing and Validation

​

Security Testing Approaches

​

Static Analysis

• SQL injection detection: Semgrep, SonarQube, and CodeQL detect string concatenation in SQL queries
• XSS detection: Identify use of dangerous sinks like innerHTML and document.write()
• Taint tracking: Advanced tools track untrusted data flow from sources to sinks

​

Negative Testing Checklist

• Inputs exceeding maximum length
• Inputs with special characters (< > " ' & ; | \)
• Unicode edge cases (null bytes, RTL override, homoglyphs)
• Boundary values (0, -1, MAX_INT, empty strings)
• Malformed encoding (invalid UTF-8, double encoding)
• Path traversal attempts (../, ..%2f, ....//)

​

Implementation Checklist

​

Conclusion

• Validate inputs at every boundary using schema-based validation with type, length, range, and format checks
• Apply context-aware output encoding using framework-provided functions
• Use parameterized queries exclusively for database access
• Avoid shell command execution; when unavoidable, use argument arrays
• Implement multi-layer file upload validation with content verification
• Enforce controls through static analysis and comprehensive testing

​

References

• OWASP Input Validation Cheat Sheet - Comprehensive input validation guidance
• OWASP XSS Prevention Cheat Sheet - Context-aware output encoding rules
• OWASP SQL Injection Prevention Cheat Sheet - Parameterized query implementation
• OWASP OS Command Injection Defense Cheat Sheet - Command injection prevention
• OWASP File Upload Cheat Sheet - Secure file upload handling
• CWE Top 25 Most Dangerous Software Weaknesses - Common vulnerability reference
• Unicode Security Considerations (TR36) - Unicode security best practices
• NIST SP 800-53 SI-10: Information Input Validation - Federal input validation requirements