Security pattern for input validation and sanitization. Use when implementing input handling, preventing injection attacks (SQL, XSS, command), ensuring data integrity, or processing data from untrusted sources. Addresses "Entity provides unexpected data" problem.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Security pattern for input validation and sanitization. Use when implementing input handling, preventing injection attacks (SQL, XSS, command), ensuring data integrity, or processing data from untrusted sources. Addresses "Entity provides unexpected data" problem.
Data Validation Security Pattern
Ensures all incoming data is validated against specifications before processing, preventing injection attacks, data corruption, and unexpected behavior.
When to Use
Use this pattern when:
Processing ANY input from external sources (users, APIs, databases)
Benefit: System only processes data in known format.
Allowlist vs. Blocklist
Allowlist (preferred): Define what IS allowed
Blocklist (risky): Define what is NOT allowed
Blocklists fail against unknown attack patterns. Use allowlists.
Validate Early, Validate Often
Validate at system boundary (earliest point)
Re-validate near code that relies on data
Defense in depth
Validation Types
Type Validation
Ensure data matches expected type
Integer, string, boolean, date, email, URL
Range/Length Validation
Numeric bounds
String length limits
Array size limits
Format Validation
Regular expressions (carefully!)
Structural patterns
Protocol conformance
Business Logic Validation
Application-specific rules
Cross-field validation
State-dependent validation
Security Considerations
Validation โ Authorization
Validation: Is this data well-formed?
Authorization: Is entity allowed to use this data?
Both are required. Valid data doesn't mean authorized access.
Error Messages
Don't reveal validation internals to attackers
Log detailed errors server-side
Return generic errors to clients
Encoding Output
Validation alone doesn't prevent all injection:
Still encode output for context (HTML, SQL, etc.)
Use parameterized queries
Use context-appropriate escaping
File Uploads
Special validation needed:
Verify content type (not just extension)
Scan for malware
Restrict file sizes
Store outside web root
Structured Data (JSON, XML)
Parse with secure parser
Disable external entity processing (XXE)
Validate against schema
Limit nesting depth
Regular Expression Safety
Avoid ReDoS-vulnerable patterns
Limit input length before regex
Test regex performance with malicious input
Common Validation Scenarios
Input Type
Validations
Username
Length, allowed characters, no control chars
Email
Format, length, allowlist domains (if applicable)
Integer
Type, range, positive/negative
URL
Protocol allowlist, format, no javascript:
File
Extension, content-type, size, malware scan
JSON
Schema validation, depth limits, size limits
Implementation Examples
Python (Pydantic / Flask)
BAD (Vulnerable):
# โ VULNERABILITY: Manual, incomplete validation@app.route("/user", methods=["POST"])defcreate_user():
data = request.get_json()
if'email'notin data: # What about type? Length? format?return"Missing email", 400# ... proceeding to use data['age'] which might be a string or negative
