{
    "slug": "input_validation",
    "term": "Input Validation vs Output Encoding",
    "category": "general",
    "difficulty": "beginner",
    "short": "Validation checks that input is acceptable; output encoding makes data safe for the context it's rendered in. Both are required.",
    "long": "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.",
    "aliases": [
        "data validation",
        "input sanitisation",
        "server-side validation"
    ],
    "tags": [
        "general",
        "security",
        "quality",
        "php"
    ],
    "misconception": "Client-side validation is sufficient if it covers all cases. Client-side validation is UX — it can be bypassed by disabling JavaScript or crafting raw HTTP requests. Server-side validation is the security control; client-side is purely for user experience.",
    "why_it_matters": "Unvalidated input is the root cause of injection attacks, unexpected behaviour, and data corruption. Validating on the server side — not just the client — ensures your application only processes data it was designed to handle.",
    "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)."
    ],
    "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."
    ],
    "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."
    ],
    "related": [
        "xss",
        "sql_injection",
        "htmlspecialchars",
        "filter_var"
    ],
    "prerequisites": [
        "allowlist_vs_blocklist",
        "filter_var",
        "type_declarations"
    ],
    "refs": [
        "https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html"
    ],
    "bad_code": "// Sanitising instead of validating — trying to fix bad input rather than reject it\n\\$email = strip_tags(\\$_POST['email']);\n\\$age   = (int) \\$_POST['age']; // -1 passes silently",
    "good_code": "// Validate — reject anything that doesn't match expectations\n\\$email = filter_var(\\$_POST['email'] ?? '', FILTER_VALIDATE_EMAIL)\n    ?: throw new \\InvalidArgumentException('Invalid email');\n\n\\$age = filter_var(\\$_POST['age'] ?? '', FILTER_VALIDATE_INT,\n    ['options' => ['min_range' => 0, 'max_range' => 150]])\n    ?: throw new \\InvalidArgumentException('Invalid age');\n\n// In Laravel — Form Request\nclass StoreUserRequest extends FormRequest {\n    public function rules(): array {\n        return [\n            'email' => ['required', 'email:rfc,dns', 'max:255', 'unique:users'],\n            'age'   => ['required', 'integer', 'between:0,150'],\n            'role'  => ['required', Rule::in(['user', 'editor'])],\n        ];\n    }\n}",
    "quick_fix": "Validate type, format, length, and range at the entry point; use allowlists not blocklists; reject invalid input early with a 400 response",
    "severity": "high",
    "effort": "low",
    "created": "2026-03-13",
    "updated": "2026-03-25",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/input_validation",
        "html_url": "https://codeclaritylab.com/glossary/input_validation",
        "json_url": "https://codeclaritylab.com/glossary/input_validation.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Input Validation vs Output Encoding](https://codeclaritylab.com/glossary/input_validation) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/input_validation"
            }
        }
    }
}