securitylisted

# /security — Security-First Design Enforcement Every design, plan, and implementation MUST treat security as a first-class constraint, not an afterthought. Vulnerabilities are bugs — the most expensive kind. **Why this matters:** A single security vulnerability can compromise user data, destroy trust, and cost millions in breach response. Security cannot be "added later" — it must be designed in from the start. Every line of code is an attack surface. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to ALL code — there are no exceptions for "internal" or "low-risk" systems. --- ## The Rules ### Rule 1: Validate All Input at System Boundaries Every piece of data entering the system MUST be validated before use: | Boundary | What to validate | |----------|-----------------| | HTTP requests | Body, query params, headers, path params — type, length, format, range | | File uploads | Type, size, content (not just extension), filename sanitization | | Database reads | Assume data could be corrupted — validate on read if used in security decisions | | Environment variables | Type, format, required vs optional — fail fast on invalid config | | External API responses | Schema validation — don't trust upstream services blindly | | User-generated content | Sanitize for XSS, SQL injection, path traversal, command injection | **Allowlist over denylist.** Define what I