Input Validation vs Output Encoding

Also Known As

TL;DR

Explanation

Input validation and output encoding are complementary — not alternatives. Validation (reject unexpected characters, enforce length and format) reduces the attack surface and catches mistakes early. Output encoding (htmlspecialchars for HTML, parameterised queries for SQL, json_encode for JS) makes data structurally safe for its destination context. Relying on validation alone fails because valid-looking data can still be malicious in a different context. Encode for the output context regardless of how the input was validated.

Common Misconception

Why It Matters

Common Mistakes

• Relying on client-side (JavaScript) validation alone — it is trivially bypassed with browser dev tools.
• Validating format but not range — accepting a birth year of 9999 is a validation failure.
• Blocklisting known bad input instead of allowlisting known good — attackers always find new bypass strings.
• Validating on the way in but re-using stored data later without re-validation (second-order attacks).

Avoid When

• Validating only on the client side — client-side validation is for UX; server-side validation is for security.
• Using validation as a substitute for parameterised queries — validate AND use prepared statements.
• Allowlist validation that is too permissive — a regex that allows < and > defeats XSS protection.
• Validating after business logic has already acted on the input — validate at the entry point, before any processing.

When To Use

• Every piece of data entering the system from an external source — user input, API payloads, file uploads, query strings.
• Allowlist validation (accept only known-good patterns) rather than blocklist (reject known-bad).
• Before passing data to any downstream system — database, shell command, template engine, serialiser.
• Structured data like emails, URLs, dates — use format-specific validators, not generic string checks.

Code Examples

// Sanitising instead of validating — trying to fix bad input rather than reject it
\$email = strip_tags(\$_POST['email']);
\$age   = (int) \$_POST['age']; // -1 passes silently

// Validate — reject anything that doesn't match expectations
\$email = filter_var(\$_POST['email'] ?? '', FILTER_VALIDATE_EMAIL)
    ?: throw new \InvalidArgumentException('Invalid email');

\$age = filter_var(\$_POST['age'] ?? '', FILTER_VALIDATE_INT,
    ['options' => ['min_range' => 0, 'max_range' => 150]])
    ?: throw new \InvalidArgumentException('Invalid age');

// In Laravel — Form Request
class StoreUserRequest extends FormRequest {
    public function rules(): array {
        return [
            'email' => ['required', 'email:rfc,dns', 'max:255', 'unique:users'],
            'age'   => ['required', 'integer', 'between:0,150'],
            'role'  => ['required', Rule::in(['user', 'editor'])],
        ];
    }
}

References

• ↗ https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

Tags

Related Terms