Coding Input Sanitization

coding-input-sanitization

Overview

Untrusted input is sanitized at the TRUST BOUNDARY - the edge of an application or a public/facing API - in two directions: validate-and-bound on the way IN, escape-for-the-sink on the way OUT.

Core principle: sanitize at the boundary, not in the libraries between boundaries. A library called by your own trusted code assumes its inputs were already validated at the edge; re-sanitizing on every internal call is waste and false confidence. Two distinct defenses, both required: input validation does NOT make output safe, and output escaping does NOT replace input validation.

Where this applies (and where it does NOT)

APPLIES - an untrusted boundary, data from outside your control:

• HTTP request body / query params / headers / cookies; web form fields; multipart file uploads
• webhook payloads; queue / broker / pub-sub messages
• CLI arguments and stdin carrying user data
• responses from a third-party API; scraped data; rows from a foreign / legacy system

DOES NOT APPLY - internal seams between trusted code:

• a domain/application function called by your own validated code
• a library/package boundary between your own modules
• These rely on the TYPE CONTRACT (the edge already validated). At most assert/typecheck; do not re-run input sanitization. Sanitizing everywhere is the anti-pattern this skill prevents.

On the way IN - validate at the edge

• Parse into a typed model, never inspect a raw dict. A boundary parser (Pydantic in Python) validates type and shape, coerces, and REJECTS what does not fit. Never pass a raw dict / JSON / ORM row inward; convert to a typed domain object immediately.
• Bound length and size. Max string length, collection size, numeric range, request-body size. Unbounded input is a DoS vector; stream or paginate large data, never materialize unbounded. For the wider self-healing/resource-guard patterns (bounding concurrency/memory, headroom checks), see bitranox:coding-resilience.
• Handle arbitrary bytes/chars. non-ASCII, emoji, CJK, control chars, NUL, binary: reject, normalize (e.g. Unicode NFC), or escape - never trust raw. Decide the allowed charset explicitly.

Test the edge with the adversarial input battery (UTF/emoji/CJK/binary/wrong-type/oversized) in bitranox:process-test-design.

On the way OUT - escape at the SINK, for that sink's context

The same value is safe for one sink and dangerous for another, so escaping belongs at the sink, not once at the edge.

Quick checklist

• Every external input parsed into a typed model at the edge; raw dict/JSON never flows inward
• Length / size / range bounded; large data streamed, not fully materialized
• Allowed charset decided explicitly; arbitrary bytes/chars rejected, normalized (NFC), or escaped
• SQL via bound parameters only; no string-built queries
• HTML autoescape ON; only trusted rich-text opts out, never a global disable
• Shell via argv, never shell=True on untrusted input
• File paths confined to a base dir; .. / absolute rejected
• No pickle / yaml.load / eval on untrusted data
• Outbound URLs allowlisted (host + scheme); internal/link-local ranges and redirects to them blocked
• CR/LF + control chars stripped before writing user data to a log line or response header
• Internal library calls NOT re-sanitized (type contract trusted)

Common mistakes

• Sanitizing everywhere. Re-validating in internal libs between trusted callers. Validate once at the boundary; trust the typed value within.
• "I validated the input, so output is safe." No - a name validated as a string is still XSS in HTML and SQLi in a concatenated query. Escape at each sink.
• Blocklist instead of allowlist. Stripping <script> or quoting one metachar is bypassable. Validate what is ALLOWED (type, charset, range) and use the sink's real escaping primitive.
• One global sanitize() that strips characters. Context-free stripping corrupts valid data and still misses context-specific attacks. There is no universal sanitizer; escape per sink.
• "It takes an argv, so there is no shell to inject into." Removing the shell removes ONE sink, not the need to validate. chpasswd reads user:password one entry PER LINE from stdin, so a newline inside a password smuggles in a second entry - run as root, that sets root's password, with no shell anywhere. Likewise a name beginning with - is parsed as an OPTION by useradd/gpasswd rather than as a name. Reject \n in a password at the boundary and allowlist account names to a POSIX pattern. The sink here is a line-oriented parser; treat it like any other sink.

Language notes

Examples are Python (the primary stack); the principle is language-agnostic. Rust: bitranox:coding-rust. Bash: bitranox:coding-bash-reference (quoting, never eval untrusted input); shlex is Python's, for building an argv from a string - see the shell sink above. Boundary-parsing architecture (where the edge is, typed models flowing inward): bitranox:coding-python-clean-architecture, bitranox:coding-python-enforce-data-architecture-strict.