Data Validation Pattern

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)
• Preventing injection attacks (SQLi, XSS, Command Injection)
• Implementing API request validation checklists
• Ensuring data integrity for business logic
• Handling file uploads or complex data structures

Problem Addressed

Entity provides unexpected data: Malicious or malformed input causes:

• Injection attacks (SQL, XSS, command injection)
• System crashes or unexpected behavior
• Data corruption
• Security bypasses

Core Components

| Role | Type | Responsibility | |------|------|----------------| | Entity | Entity | Sends data to system | | Enforcer | Enforcement Point | Intercepts all incoming data | | Validator | Decision Point | Validates data against specification | | Specification Provider | Information Point | Manages validation rules | | System | Entity | Processes validated data |

Data Elements

• data: Input from entity (raw)
• canonical_data: Normalized, validated form
• specification: Rules defining valid data
• type: Identifier for applicable specification
• error: Validation failure message

Validation Flow

Entity → [data] → Enforcer
Enforcer → [data] → Validator
Validator → [get_specification(type)] → Specification Provider
Specification Provider → [specification] → Validator
Validator → [validate, transform to canonical] → Validator
Validator → [canonical_data or error] → Enforcer
Enforcer → [canonical_data] → System (if valid)
        → [error] → Entity (if invalid)

1. Enforcer intercepts ALL incoming data
2. Validator retrieves appropriate specification
3. Validator transforms to canonical form
4. Validator checks against specification
5. Valid: canonical data forwarded to System
6. Invalid: error returned to Entity

Validation Principles

Validate Everything

• All data from uncontrolled sources
• Parameters, headers, cookies, files
• Data from APIs, databases (defense in depth)

Canonical Form

Transform data to standardized form:

• Remove/escape special characters
• Decode encoded values
• Normalize Unicode
• Parse structured data to typed objects

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"])
def create_user():
    data = request.get_json()
    if 'email' not in data: # What about type? Length? format?
        return "Missing email", 400
    # ... proceeding to use data['age'] which might be a string or negative

GOOD (Secure):

from pydantic import BaseModel, EmailStr, conint, constr

# ✅ Define strict schema
class UserSchema(BaseModel):
    username: constr(min_length=3, max_length=50, pattern=r'^[a-zA-Z0-9_]+$')
    email: EmailStr
    age: conint(ge=18, le=120)

@app.route("/user", methods=["POST"])
def create_user():
    try:
        # ✅ Validate payload against schema
        user = UserSchema(**request.get_json())
        save_to_db(user.model_dump())
    except ValueError as e:
        return jsonify({"error": str(e)}), 400

JavaScript (Zod / Express)

BAD (Vulnerable):

// ❌ VULNERABILITY: Implicit trust
app.post('/api/profile', (req, res) => {
    // trusting req.body.website is a valid URL
    // trusting req.body.role is not "admin"
    updateProfile(req.user.id, req.body);
});

GOOD (Secure):

const { z } = require('zod');

// ✅ Define strict schema
const ProfileSchema = z.object({
    website: z.string().url().max(100),
    bio: z.string().max(500).optional(),
    role: z.enum(['user', 'editor']), // Block 'admin'
});

app.post('/api/profile', (req, res) => {
    const result = ProfileSchema.safeParse(req.body);

    if (!result.success) {
        return res.status(400).json(result.error);
    }

    // ✅ Apply canonical/validated data
    updateProfile(req.user.id, result.data);
});

Implementation Checklist

• [ ] All entry points have validation
• [ ] Canonical form transformation
• [ ] Allowlist-based rules
• [ ] Type checking
• [ ] Length/range limits
• [ ] Business rule validation
• [ ] Secure error handling
• [ ] Output encoding (separate from validation)
• [ ] File upload validation
• [ ] Structured data parsing safely
• [ ] Re-validation near sensitive operations

Related Patterns

• Authorisation (validation doesn't replace authorization)
• Selective encrypted transmission (protect data in transit)
• Log entity actions (log validation failures)

References

• Source:
• OWASP Input Validation Cheat Sheet
• OWASP XSS Prevention Cheat Sheet

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: igbuend
• Source: igbuend/grimbard
• License: MIT

Install and usage instructions live in the source repository linked above.