input-validation-injectionlisted

# Input Validation and Injection Defense Ensure untrusted input is validated and never interpreted as code. Prevent injection across SQL, LDAP, OS commands, templating, and JavaScript runtime object graphs. ## Core Strategy - Validate early at trust boundaries with positive (allow-list) validation and canonicalization. - Treat all untrusted input as data, never as code. Use safe APIs that separate code from data. - Parameterize queries/commands; escape only as last resort and context-specific. ## Validation Playbook - **Syntactic validation**: enforce format, type, ranges, and lengths for each field. - **Semantic validation**: enforce business rules (e.g., start <= end date, enum allow-lists). - **Normalization**: canonicalize encodings before validation; validate complete strings (regex anchors `^$`); beware ReDoS. - **Free-form text**: define character class allow-lists; normalize Unicode; set length bounds. - **Files**: validate by content type (magic), size caps, and safe extensions; server-generate filenames; scan; store outside web root. ## SQL Injection Prevention - Use prepared statements and parameterized queries for 100% of data access. - Use bind variables for any dynamic SQL within stored procedures -- never concatenate user input into SQL. - Prefer least-privilege DB users and views; never grant admin to app accounts. - Escaping is fragile and discouraged; parameterization is the primary defense. Example (Java PreparedStatement): ```java String custname