Input Validation and Output Encoding Guide: Context-Aware Defences Against Injection

Injection happens when data crosses into an interpreter and is read as code, and no amount of filtering at the front door can know every interpreter the data will reach later. Input validation and output encoding are the two controls that stop it, but they do different jobs at different points in the code, and most injection bugs come from using one where the other belongs. This guide sets out how to design validation rules that hold up, which encoding or parameterisation each interpreter needs (SQL, shell, HTML, JavaScript, URLs, logs, CSV, CI scripts and more), where in the architecture each control should live, and how to roll it out and measure it. It is written for developers, AppSec engineers and reviewers; the deep dives on individual injection classes are linked from each row.

Key takeaways

• Validate for correctness, encode for safety. Validation at the trust boundary checks that data makes sense for the business; encoding or parameterisation at the sink stops it changing the structure of a query, page or command.
• The sink decides the defence. HTML body, HTML attribute, JavaScript string, URL, SQL value, SQL identifier, shell argument and log line each need a different control, and the wrong one can be worse than none.
• Decode once, then validate. ASVS 5.0 V1.1.1 requires input to be decoded into canonical form once, before validation; a second decode downstream reopens everything the validator closed.
• Allowlists for structure, never denylists for safety. Stripping quotes or angle brackets breaks legitimate data and still does not make a query or page safe.
• Parameterise names as well as values. Column names, sort keys and JSON field names that reach SQL need an allowlist mapping, as the 2026 McKinsey Lilli case showed.

Four controls and what each one is for

OWASP's Input Validation Cheat Sheet is direct about the division of labour: use parameterised queries for SQL and context-aware output encoding for cross-site scripting, and check authorisation separately, because a valid identifier does not mean the caller may use it. CWE-20 (Improper Input Validation) reaches the same conclusion through its own example, where a birthday field restricted to digits and dashes still let a payload through, and concludes that encoding combined with validation is the useful protection.

Validation should come first because rejecting malformed data early keeps it out of storage, logs and downstream systems. Encoding has to be last because only the code that writes to the sink knows which interpreter will read the result.

Designing validation rules that hold up

Validate both syntax (the expected type and format) and semantics (whether the value makes sense, for example an end date after a start date). ASVS 5.0 V2.2.1 asks for positive validation against allowed values, patterns and ranges, applied to all input from Level 2, and V2.2.2 requires it at a trusted service layer, not only in the browser.

• Limit before you parse: apply request size limits before buffering, and parser limits such as maximum JSON nesting depth. RFC 8259 explicitly allows implementations to limit size, depth and numbers. A schema check after parsing cannot protect the parser.
• Close the schema: in JSON Schema, set "additionalProperties": false and an explicit required list; listing a property alone neither requires it nor rejects unknown fields. Bind only intended fields to objects to avoid mass assignment.
• Decode once, in one place: decode percent-encoding, HTML entities or Base64 according to the protocol, validate the decoded value, and never decode again downstream. CWE-20 points to double decoding (CWE-174) as a way dangerous input slips past an allowlist; CAPEC-267 Leverage Alternate Encoding describes the attacker side.
• Regex with whole-value matching and bounded cost: use full-match APIs such as Python re.fullmatch, bound length before matching, and avoid patterns with catastrophic backtracking (ASVS V1.3.12). Use a non-backtracking engine or match timeout where available.
• Unicode policy: agree one character encoding (UTF-8) across components, reject malformed sequences, and if a field needs normalisation for comparison, apply the same form (for example NFC or NFKC under Unicode Annex #15) before validation, storage and comparison.
• Validate internal sources too: partner feeds, queues, stored records and AI model output cross trust boundaries even when the transport is internal.
• Reject, do not repair: fail the request with a clear error rather than continuing with partially validated or "cleaned" data.

The sink map: matching the defence to the interpreter

This is the core reference. For each place untrusted data ends up, use the defence in the second column; encoding is listed only where parameterisation is not available.

Where encoding belongs in the architecture

• Store raw, encode on output: keep the canonical value in the database and encode for the sink at render time. Data encoded for HTML on the way in is wrong in a CSV export, a JSON API or an email, and gets double-encoded when a template escapes it again.
• Let the interpreter's own API do it: prepared statements, subprocess argument lists, textContent and setAttribute() separate data from code without any string encoding. ASVS V1.1.2 accepts encoding "by the interpreter itself" for this reason.
• Use auto-escaping templates and audit the escape hatches: most frameworks escape by default; the risk sits in |safe, raw, Html.Raw(), v-html, bypassSecurityTrustHtml and similar. Inventory them and require review for each new use.
• One vetted encoder library per platform: for example the OWASP Java Encoder, or the framework's built-in encoders in .NET and Python templating. CWE-116 (Improper Encoding or Escaping of Output) recommends vetted libraries over hand-written escaping.
• No global input filters: a WAF or middleware that strips characters from every request cannot know the output context and breaks legitimate data. Keep a WAF as detection and virtual patching, not as the control.
• Declare character sets: every response with a body should carry a Content-Type with charset (ASVS V4.1.1), so the browser and the encoder agree on what the bytes mean.
• Sanitise rich content once, with a maintained library: for HTML from editors use a sanitiser such as DOMPurify (ASVS V1.3.1) and do not modify its output afterwards. Details are in the Cross-Site Scripting (XSS) Prevention Guide.

Implementation roadmap

1. Map sinks: use SAST to list every database call, process launch, template render, DOM write, log call and export function, and tag each with its interpreter. This is the scope for the rest of the plan.
2. Fix the highest-impact sinks first: concatenated SQL and shell commands reachable from unauthenticated endpoints, then escape hatches in templates, then everything else.
3. Publish validation contracts: define schemas for every external API (OpenAPI with JSON Schema, Protocol Buffers) with closed objects, bounds and formats, as ASVS V2.1.1 requires documented rules. See the Secure API Design Guide.
4. Enforce in report-only mode: run schema validation and new encoders in log-only mode in a pilot ring for one to two weeks, review rejections for false positives (legitimate names, scripts, punctuation), then switch to reject.
5. Gate the pipeline: add SAST rules that fail on new concatenated queries, shell string execution, unsafe DOM sinks and template escape hatches; add negative tests for each validation rule (out of range, unknown field, oversize array, near-matching values).
6. Roll back safely: keep validation enforcement behind a per-route flag so a false-positive rule can return to report-only without redeploying; never roll back a parameterisation fix.
7. Extend to non-web sinks: logs, CSV exports, email, CI workflows and LLM integrations, which scanners usually miss.

Decision guidance

• Reject or sanitise? Reject when the field has a defined format. Sanitise only when users must submit rich content, and then with a library, never a regex.
• Gateway or service validation? Use both: the API gateway enforces size limits and schema shape cheaply, the service enforces semantics and authorisation, which the gateway cannot see.
• Encoding or parameterisation? Parameterise wherever the interpreter offers it. Encoding is the fallback for sinks that are text formats (HTML, CSV, logs).
• Small teams: rely on framework defaults (ORM, auto-escaping templates, schema validation middleware) and a short list of banned APIs in CI. That covers most of the risk at low cost.
• Large organisations: publish an approved library list per language, central schema registries for APIs, and a sink inventory tracked in ASPM tooling, with exceptions approved by AppSec.

Detection and measurement

• Log validation failures as security events: ASVS V16.3.3 expects attempts to bypass controls to be logged. Record the rule, field and source, not the raw value, and encode anything retained (V16.4.1).
• Watch database and interpreter errors: syntax errors from the database driver, template engine or shell in production usually mean a sink received structure it did not expect. In the McKinsey case, field names reflected in database error messages were what exposed the query structure.
• Alert on exploitation follow-on: injection into public applications maps to T1190 Exploit Public-Facing Application; command injection then shows as shells spawned by application processes (T1059).

Metrics:

• Open injection-class findings (CWE-89, CWE-78, CWE-79, CWE-117) by severity and age.
• Percentage of external API operations with a closed, enforced schema.
• Count of template escape hatches and unsafe DOM sinks, trended to zero or to reviewed exceptions.
• Validation rejection rate per route, with false-positive rate from report-only pilots.
• Production interpreter syntax errors per week (database, template, shell).

Framework mapping

Common failure patterns

• Client-side only validation: browser checks are for usability; anything that calls the API directly bypasses them.
• Denylist "cleaning": removing suspicious characters changes meaning, blocks real names and still leaves the sink unprotected.
• Encoding on input: HTML-encoding at save time produces double-encoded pages and unprotected non-HTML outputs.
• Parameterised values, concatenated names: dynamic column lists, sort keys and filter field names are left out of the bind mechanism.
• Trusting internal or "metadata" fields: branch names, filenames, HTTP headers and partner feeds are attacker-controllable more often than teams assume.
• Logging raw rejected input: creates log injection and puts secrets and personal data into log stores. See the Secure Error Handling and Logging Guide.

Lessons from incidents

• McKinsey Lilli (2026): an unauthenticated endpoint parameterised search values but concatenated JSON field names into SQL; standard scanners did not flag it, and an autonomous agent inferred the query from error messages. See McKinsey AI Platform Hack 2026. Lesson: identifiers need allowlist mapping, and verbose database errors help attackers.
• Ultralytics (2024): a GitHub Actions workflow on pull_request_target inserted a pull request's branch name into a shell script, so an attacker-chosen branch name ran commands in a privileged CI context and led to poisoned releases. See Ultralytics PyPI Compromise 2024. Lesson: CI scripts are an injection sink, and the fix is the same as for any shell: pass data as variables, never as code.

Practitioner checklist

• Inventory sinks by interpreter and record the required defence for each from the sink map.
• Replace every concatenated SQL, LDAP, XPath and shell call with parameterised APIs; map identifiers through allowlists.
• Define closed schemas with bounds for all external APIs and enforce them on the server.
• Decode input once, before validation, and use one URL parser and one character encoding across components.
• Keep auto-escaping on, inventory template escape hatches and unsafe DOM sinks, and require review for new ones.
• Store raw values and encode at output with one vetted encoder library per platform.
• Escape logs, CSV exports, response headers and CI workflow inputs, not just web pages.
• Run new validation rules in report-only mode first, with a per-route rollback flag.
• Fail builds on new unsafe sinks and add negative tests for each validation rule.
• Track the five metrics above and review exceptions quarterly.

Standards and references

• OWASP: Application Security Verification Standard 5.0
• OWASP: Input Validation Cheat Sheet
• OWASP: Cross Site Scripting Prevention Cheat Sheet
• OWASP: Injection Prevention Cheat Sheet
• MITRE: CWE-20 Improper Input Validation
• MITRE: CWE-116 Improper Encoding or Escaping of Output
• NIST: SP 800-53 Rev. 5
• GitHub: Security hardening for GitHub Actions

Related NHI Mgmt Group resources: Cross-Site Scripting (XSS) Prevention Guide · SQL Injection Prevention Guide · Secure Deserialisation Guide · Secure Coding Guide · Content Security Policy Guide