coding-input-sanitizationlisted

# 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 parse