Input validation and sanitization flow
Validate format, sanitize dangerous content, protect against injection attacks.
Input validation is your first line of defense against data corruption and security attacks. This template shows the flow: receive user input, validate format and bounds, then sanitize dangerous content. The diagram separates concerns: validation rejects obviously wrong input (missing, wrong format, too long); sanitization makes valid-looking input safe (removing HTML tags, escaping SQL sequences).
Most security incidents start with invalid input that a developer trusted. A user enters a password with a quote character, the code doesn't escape it, and suddenly your SQL query breaks or becomes vulnerable. Validation catches obvious mistakes; sanitization catches sneaky input that looks valid but contains hidden code.
When to use this template
- Form validation design — before writing HTML validation + backend checks, sketch the flow so product, design, and engineering agree on what inputs are accepted and how you handle errors.
- API endpoint hardening — every endpoint that accepts user input needs this flow. Use it as a checklist: do we validate format, check length, escape special characters?
- Security reviews — show auditors the validation + sanitization pipeline so they can spot gaps (is email validation case-sensitive? do we escape user-supplied URLs?)
How to adapt it
Customize validation rules for your inputs:
- Phone number validation — country-specific formats (US 10-digit, UK 11-digit), international formats. Add a regional routing node.
- File upload validation — check file type (extension and MIME type), file size, scan for malware. Add a virus-scan step before storing.
- Credit card validation — Luhn algorithm for checksum, length and prefix (Visa starts with 4, Amex starts with 3). Never log full card numbers; use tokenization.
Visual edits regenerate clean Mermaid code, so you can expand this diagram with domain-specific validation rules.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Receive user input] --> B[Check input exists]
B -->|Missing| C[Return 400 Bad Request]
B -->|Present| D[Validate format]
D -->|Invalid format| C
D -->|Valid format| E[Check length/bounds]
E -->|Exceeds limits| C
E -->|Within limits| F[Sanitize special characters]
F --> G[Remove HTML tags if needed]
G --> H[Escape SQL/script sequences]
H --> I{Input type?}
I -->|Email| J[Verify email format + domain]
I -->|URL| K[Verify protocol + domain]
I -->|Plain text| L[Allow sanitized content]
J --> M{Validation passed?}
K --> M
L --> M
M -->|No| C
M -->|Yes| N[Store in database]
N --> O[Return 200 OK]
Frequently asked questions
- What is the difference between validation and sanitization?
- Validation checks if input matches expected format (is it a valid email? is the phone number 10 digits?). Sanitization modifies input to remove or escape dangerous content (stripping HTML tags, escaping SQL metacharacters). Both are needed: validation rejects obviously wrong input; sanitization protects valid-looking input from injection attacks. Validate first (fail fast), then sanitize (defense in depth).
- Why do I need to escape SQL sequences?
- SQL injection is an attack where a user enters SQL code as input, and the application concatenates it into a query without escaping. Example: entering '; DROP TABLE users; -- as a password and the database executes the drop command. Escaping special characters (quotes, semicolons) makes them literals instead of code. Better: use parameterized queries (the database separates code from data automatically), which prevent injection entirely.
- Should I remove HTML tags from user input?
- Depends on context. If you're storing user comments and rendering them as text (not HTML), remove or escape HTML tags so a user can't inject malicious scripts. If you're building a rich-text editor and intentionally allow HTML, use a whitelist (allow only safe tags like <b>, <i>, <p>) and strip everything else. Never trust user HTML. Strip by default, allow HTML only when you've carefully vetted what tags are safe.
- How do I test that my validation actually works?
- Create test cases for boundary conditions: empty input, extremely long input (1MB strings), special characters (quotes, semicolons, angle brackets, emoji), script tags, SQL keywords. Try to break the system. Visual edits regenerate clean Mermaid code, so you can expand this diagram to show your custom validation rules and share it with your team.
Related templates
Bulk data import pipeline
CSV upload, validation, transformation, database load with rollback on error.
Error handling and recovery flow
API error response paths and recovery strategies.
GraphQL mutation error recovery
Mutation execution with validation, failure paths, and rollback handling.