Input Validation and Output Encoding

Input Validation: The First Line of Defense Against Injection

Input validation is the process of ensuring that user-supplied data conforms to expected formats, types, and ranges before the application processes it. The most effective validation strategy is allow-list validation — accepting only input that matches a known-good pattern — rather than deny-list validation — rejecting input that matches known-bad patterns.

Why Allow-List Beats Deny-List

Deny-list validation attempts to block known dangerous patterns:

# DENY-LIST — blocks known-bad patterns (INSUFFICIENT)
def is_safe(input):
    dangerous = ['<script>', 'SELECT', 'DROP', 'UNION', 'OR 1=1']
    for pattern in dangerous:
        if pattern in input:
            return False
    return True

This approach fails because:

1. Attackers find gaps: The deny-list cannot anticipate every possible attack payload. URL encoding, case variation, and novel syntax all bypass static lists.
2. Context-dependent danger: The string SELECT is dangerous in a SQL context but harmless in a blog post. Deny-lists cannot account for context.
3. Maintenance burden: New attack patterns emerge constantly. The deny-list requires continuous updates.

Allow-list validation inverts the logic — it defines what is allowed and rejects everything else:

# ALLOW-LIST — accepts only known-good patterns
import re

def validate_username(username):
    # Only allow alphanumeric characters, 3-20 characters long
    if not re.match(r'^[a-zA-Z0-9]{3,20}$', username):
        raise ValueError('Invalid username format')
    return username

def validate_age(age):
    # Only allow integers between 0 and 150
    try:
        age_int = int(age)
        if not (0 <= age_int <= 150):
            raise ValueError
        return age_int
    except (ValueError, TypeError):
        raise ValueError('Invalid age')

Validation at Trust Boundaries

Validation must occur at every trust boundary — any point where data crosses from a less-trusted zone to a more-trusted zone:

1. External input: HTTP request parameters, headers, body, file uploads
2. Inter-process communication: Message queues, RPC calls between services
3. Database output: Data retrieved from the database may have been modified by another service or contain legacy data
4. File system: Configuration files, uploaded files, cached data

Critical principle: Client-side validation (JavaScript in the browser) is a usability feature, not a security control. Attackers can bypass it entirely by sending direct HTTP requests. Server-side validation is mandatory.

Validation Strategies by Data Type

Strings: Use regular expressions to define exact patterns.

# Email validation (simplified)
EMAIL_RE = re.compile(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$')

Numbers: Parse to the correct type and validate range.

# Integer with range
value = int(input_str)
if not (1 <= value <= 100):
    raise ValueError

Enumerations: Validate against a fixed set of allowed values.

ALLOWED_SORT_FIELDS = {'name', 'date', 'price'}
if sort_field not in ALLOWED_SORT_FIELDS:
    raise ValueError('Invalid sort field')

Dates: Parse with a strict format and validate range.

from datetime import datetime
try:
    date = datetime.strptime(date_str, '%Y-%m-%d')
except ValueError:
    raise ValueError('Invalid date format')

Files: Validate file type by content (magic bytes), not just extension. Limit file size.

import magic
file_type = magic.from_buffer(file_content, mime=True)
if file_type not in ('image/png', 'image/jpeg'):
    raise ValueError('Invalid file type')

Output Encoding: Escaping Data for the Correct Context

Input validation reduces the attack surface, but it cannot eliminate all injection risks. Output encoding is the complementary defense — it ensures that data is safely rendered in the specific context where it appears, regardless of what the data contains.

Why Both Are Necessary

Consider a username field that allows hyphens (for names like mary-jane). An attacker registers the username mary-jane"><script>alert(1)</script>. Input validation rejects it because it contains < and >. But what if the username is mary-jane'onmouseover='alert(1)? This passes validation (no angle brackets) but is dangerous in an HTML attribute context.

Output encoding handles this by escaping the data for the specific context where it will be rendered.

Encoding by Context

HTML Body Context

When data appears between HTML tags:

<div>USER_DATA_HERE</div>

Escape <, >, &, ", and ':

import html
safe = html.escape(user_input)
# < > & " ' become &lt; &gt; &amp; &quot; &#x27;

HTML Attribute Context

When data appears inside an HTML attribute value:

<input value="USER_DATA_HERE">

Escape quotes in addition to HTML entities:

safe = html.escape(user_input, quote=True)
# Also escapes " and '

JavaScript Context

When data appears inside a <script> block or JavaScript string:

<script>
  var name = 'USER_DATA_HERE';
</script>

Use JSON encoding for JavaScript string values:

const safe = JSON.stringify(userInput);
// Escapes quotes, backslashes, and control characters

URL Context

When data appears in a URL parameter:

https://example.com/search?q=USER_DATA_HERE

Use percent-encoding:

const safe = encodeURIComponent(userInput);

CSS Context

When data appears in a CSS value:

.content::before { content: "USER_DATA_HERE"; }

CSS encoding is complex. The safest approach is to use a strict allow-list of allowed characters:

import re
safe = re.sub(r'[^a-zA-Z0-9\s\-_]', '', user_input)

Common Encoding Mistakes

1. Using the wrong encoder for the context:

# WRONG — HTML encoding does not protect JavaScript context
safe = html.escape(user_input)
return f'<script>var name = "{safe}"</script>'
# Attacker input: "; alert(1); //
# HTML escape does not escape quotes in JS context

2. Double-encoding:

# WRONG — encoding already-encoded data
safe = html.escape(html.escape(user_input))
# Results in < instead of <

3. Encoding at the wrong layer:

# WRONG — encoding before storage
user_input = html.escape(request.POST['comment'])
db.store(user_input)  # Stores encoded data
# Later retrieval shows encoded entities to users

Encode at the point of output, not at the point of input.

Practice: Fix the Output Encoding

The following code has an output encoding vulnerability. Identify and fix it:

@app.route('/greet')
def greet():
    name = request.args.get('name', 'Guest')
    # VULNERABLE — name is inserted into HTML without encoding
    return f'<h1>Hello, {name}!</h1>'

An attacker supplies name=<script>alert(1)</script> and the script executes.

Fix:

import html

@app.route('/greet')
def greet():
    name = request.args.get('name', 'Guest')
    safe_name = html.escape(name)
    return f'<h1>Hello, {safe_name}!</h1>'

The html.escape() function converts < to <, > to >, and & to &, preventing the browser from interpreting the input as HTML.