ya-te-lavaste-las-manoslisted

# ¿Ya te lavaste las manos? It does not matter that the data looks fine. You do not know where it has been. ## Rule Data from outside this process is dirty until it is validated at the trust boundary, and it stays dangerous at every sink it reaches. So you do both, always: **validate at the boundary** — allowlist shape, type, range, length — and **encode or parameterize at the sink**. Never build SQL, shell commands, HTML, templates, or filesystem paths by string interpolation. "It was validated upstream" is not a defense; upstream is not this line. ## Procedure Run steps 1–6 in order for the change in front of you. 1. **List every untrusted entry point it touches.** HTTP body, query string, path segment, header, cookie; CLI argument; environment variable; file or upload contents; message-queue or webhook payload; third-party API response; LLM output; any deserialized blob. If a value did not originate in this codebase, it is on the list. 2. **Trace each entry point to every sink it reaches.** Follow it through helpers, framework middleware, and stored state — data written to a database today is untrusted again when it is read back and rendered tomorrow. Name the sinks; do not assume the path is short. 3. **Validate at the boundary.** Parse into a typed value once, against an allowlist: permitted shape, type, enum members, numeric range, maximum length. Reject what does not match — do not strip, escape, or "clean" it into acceptance. Rejection is