Why Validate Input?

Every piece of data that enters your application from an external source is a potential attack vector. User input, query parameters, HTTP headers, file uploads, API payloads, and even data from your own database (if it was stored without validation) can all carry malicious content.

Input validation is the first line of defense in the secure coding chain. Without it, your application becomes vulnerable to an entire class of injection attacks.

• SQL Injection - Malicious SQL statements inserted through form fields to manipulate or extract database content
• Cross-Site Scripting (XSS) - JavaScript injected into pages that executes in other users' browsers
• Command Injection - Operating system commands embedded in input that execute on the server
• Path Traversal - File paths crafted to access files outside the intended directory (e.g., ../../etc/passwd)
• LDAP Injection - Malicious LDAP queries injected through search or authentication fields
• Data Corruption - Invalid data that breaks application logic, causes crashes, or corrupts stored records

Client-Side vs. Server-Side Validation

Validation can happen in two places: the browser (client-side) and the server (server-side). Both serve different purposes, and understanding the distinction is critical to building secure applications.

Client-Side Validation

Client-side validation runs in the user's browser using HTML attributes or JavaScript. It provides immediate feedback and improves user experience, but it is trivially bypassable.

<!-- HTML5 built-in validation -->
<form>
    <input type="email" required maxlength="254"
           pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"
           title="Enter a valid email address" />

    <input type="number" min="1" max="100" step="1" required />

    <input type="text" minlength="3" maxlength="50" required />

    <button type="submit">Submit</button>
</form>

Server-Side Validation

Server-side validation is your actual security boundary. It runs in your backend code where the attacker cannot modify it. Every input must be validated server-side before it is processed, stored, or passed to another system.

# Python/Flask server-side validation example
from flask import request, abort
import re

@app.route('/register', methods=['POST'])
def register():
    email = request.form.get('email', '').strip()
    username = request.form.get('username', '').strip()
    age = request.form.get('age', '')

    # Validate email format
    if not re.match(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$', email):
        abort(400, 'Invalid email format')

    # Validate email length
    if len(email) > 254:
        abort(400, 'Email too long')

    # Validate username: alphanumeric, 3-30 chars
    if not re.match(r'^[a-zA-Z0-9_]{3,30}$', username):
        abort(400, 'Username must be 3-30 alphanumeric characters')

    # Validate age: integer in range
    try:
        age_int = int(age)
        if not (13 <= age_int <= 120):
            abort(400, 'Age must be between 13 and 120')
    except ValueError:
        abort(400, 'Age must be a number')

    # All validation passed - proceed with registration
    create_user(email, username, age_int)

Allowlists vs. Denylists

When defining what input to accept or reject, you have two fundamental approaches. The difference between them has significant security implications.

# GOOD: Allowlist approach - only permit known-safe characters
import re

def validate_username(username):
    """Only allow alphanumeric characters and underscores, 3-30 chars."""
    if re.match(r'^[a-zA-Z0-9_]{3,30}$', username):
        return True
    return False

# BAD: Denylist approach - try to block known-dangerous characters
def validate_username_bad(username):
    """Block dangerous characters. FRAGILE - attacker will find bypasses."""
    dangerous = ['<', '>', '"', "'", ';', '&', '|', '`', '$', '\\']
    for char in dangerous:
        if char in username:
            return False
    return True  # Accepts EVERYTHING else - unicode tricks, null bytes, etc.

Validating Common Formats

Here are secure validation patterns for data types you will encounter repeatedly. Each example uses an allowlist approach with strict bounds checking.

Email Addresses

import re

def validate_email(email):
    """Validate email format. For real verification, send a confirmation email."""
    if not email or len(email) > 254:
        return False
    # RFC 5322 simplified - covers 99% of real addresses
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return bool(re.match(pattern, email))

URLs

from urllib.parse import urlparse

def validate_url(url):
    """Accept only http/https URLs. Prevents javascript:, data:, file: schemes."""
    try:
        parsed = urlparse(url)
        # Allowlist: only http and https schemes
        if parsed.scheme not in ('http', 'https'):
            return False
        # Must have a hostname
        if not parsed.netloc:
            return False
        return True
    except Exception:
        return False

Numeric Values

def validate_integer(value, min_val, max_val):
    """Validate that a string represents an integer within bounds."""
    try:
        num = int(value)
        return min_val <= num <= max_val
    except (ValueError, TypeError):
        return False

def validate_price(value):
    """Validate a decimal price: positive, max 2 decimal places, max $999,999."""
    import decimal
    try:
        price = decimal.Decimal(value)
        if price <= 0 or price > 999999:
            return False
        if price.as_tuple().exponent < -2:
            return False  # More than 2 decimal places
        return True
    except decimal.InvalidOperation:
        return False

File Uploads

import os
import magic  # python-magic library

ALLOWED_EXTENSIONS = {'.jpg', '.jpeg', '.png', '.gif', '.pdf'}
MAX_FILE_SIZE = 5 * 1024 * 1024  # 5MB

def validate_file_upload(file):
    """Validate uploaded file by extension, MIME type, and size."""
    # Check file size
    file.seek(0, os.SEEK_END)
    size = file.tell()
    file.seek(0)
    if size > MAX_FILE_SIZE:
        return False, 'File too large (max 5MB)'

    # Check extension (allowlist)
    ext = os.path.splitext(file.filename)[1].lower()
    if ext not in ALLOWED_EXTENSIONS:
        return False, f'File type {ext} not allowed'

    # Verify MIME type matches extension (prevents extension spoofing)
    mime = magic.from_buffer(file.read(2048), mime=True)
    file.seek(0)
    allowed_mimes = {
        '.jpg': 'image/jpeg', '.jpeg': 'image/jpeg',
        '.png': 'image/png', '.gif': 'image/gif',
        '.pdf': 'application/pdf'
    }
    if mime != allowed_mimes.get(ext):
        return False, 'File content does not match extension'

    return True, 'Valid'

Sanitization Techniques

Sanitization transforms input to make it safe, as opposed to validation which rejects unsafe input entirely. The two are complementary. Validate first (reject obviously bad input), then sanitize what passes validation before using it.

String Trimming and Normalization

def sanitize_string(value):
    """Basic string sanitization."""
    if not isinstance(value, str):
        return ''

    # Strip leading/trailing whitespace
    value = value.strip()

    # Remove null bytes (used in null byte injection attacks)
    value = value.replace('\x00', '')

    # Normalize unicode to prevent homoglyph attacks
    import unicodedata
    value = unicodedata.normalize('NFKC', value)

    # Collapse multiple spaces into one
    value = ' '.join(value.split())

    return value

HTML Sanitization

# Using the bleach library (Python) for safe HTML
import bleach

def sanitize_html(user_html):
    """Allow only safe HTML tags and attributes."""
    allowed_tags = ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'a', 'code']
    allowed_attrs = {'a': ['href', 'title']}
    allowed_protocols = ['http', 'https']

    return bleach.clean(
        user_html,
        tags=allowed_tags,
        attributes=allowed_attrs,
        protocols=allowed_protocols,
        strip=True  # Remove disallowed tags entirely (don't escape them)
    )

# Example:
# Input:  '<p>Hello</p><script>alert("xss")</script><img onerror="hack()">'
# Output: '<p>Hello</p>'

SQL Parameterization (Not Sanitization)

# NEVER do this - string concatenation with user input
query = f"SELECT * FROM users WHERE username = '{username}'"  # VULNERABLE

# ALWAYS use parameterized queries
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

# With an ORM (SQLAlchemy example)
user = session.query(User).filter(User.username == username).first()

Encoding Output

Output encoding is the complement to input validation. Even if you validate and sanitize input perfectly, you must encode it appropriately when rendering it in different contexts. The encoding you need depends on where the data appears in the output.

<!-- HTML encoding - use your template engine's auto-escape -->
<!-- Jinja2 (Python): auto-escapes by default -->
<p>Welcome, {{ username }}</p>

<!-- Safe JavaScript embedding -->
<script>
    // GOOD: JSON-encode server data into a variable
    const userData = {{ user_data | tojson }};

    // BAD: Direct string interpolation
    // const name = '{{ username }}';  // XSS if username contains quotes
</script>

<!-- URL encoding -->
<a href="/search?q={{ query | urlencode }}">Search results</a>

Common Mistakes

Even developers who understand input validation in theory frequently make these mistakes in practice. Each of these has led to real-world security breaches.

• Validating only on the client side - JavaScript validation is a UX feature, not a security control. An attacker sends requests directly to your server endpoint and bypasses all browser-side checks.
• Using denylists instead of allowlists - Blocking <script> tags but forgetting about <img onerror=...>, <svg onload=...>, or Unicode encoding tricks. Attackers always find what you forgot to block.
• Trusting hidden form fields - Hidden fields (<input type="hidden">) are trivially editable. A hidden field containing a user ID or price is just as attackable as a text input.
• Validating input but not encoding output - Input validation and output encoding serve different purposes. Even validated data must be encoded for the context where it is rendered (HTML, JavaScript, SQL, URL).
• Inconsistent validation - Validating input at the web controller but not at the API endpoint, or validating on insert but not on update. Every entry point needs validation.
• Rolling your own sanitization for SQL - Writing custom functions to escape quotes instead of using parameterized queries. This approach has been broken countless times and will be broken again.
• Forgetting about HTTP headers and cookies - Validating form fields but directly using User-Agent, Referer, or cookie values without sanitization. These are attacker-controlled.
• Insufficient length limits - Allowing megabytes of data in a "name" field, enabling denial-of-service through storage exhaustion or expensive regex processing (ReDoS).

Summary

In this tutorial, you learned:

• Why input validation is the first line of defense against injection attacks and data corruption
• The critical difference between client-side validation (UX) and server-side validation (security)
• Why allowlists are fundamentally more secure than denylists for defining acceptable input
• How to validate common formats including emails, URLs, numbers, and file uploads
• Sanitization techniques for strings, HTML content, and why parameterized queries replace SQL sanitization
• Context-dependent output encoding for HTML, JavaScript, URL, and CSS contexts
• The most common input validation mistakes and how to avoid them