MUST USE for security-sensitive code — XSS, CSRF, SQL injection, JWT, OAuth, secrets, OWASP, auth hardening, supply chain, threat model. Triggers: auth/login/token code, input validation at trust boundaries, dependency/release surface, security/threat_model task_tags.
metadata
{"short-description":"Security as a build constraint: OWASP, auth hardening, secrets, supply chain.","keywords":"xss, csrf, sql injection, jwt, oauth, secrets, owasp, auth hardening, supply chain, threat model, slopsquatting","injection_condition":"security-sensitive code, or security/threat_model task_tags","last-verified":"2026-07-02"}
Dev-Security — Production Security Hardening
Treat security as a build constraint, not a cleanup step.
This skill is the authoritative source for authentication, authorization, input validation, secrets, headers, rate limiting, supply-chain checks, PII handling, and agentic AI safety.
Validation ownership split: this skill owns what the validation schema enforces (content/policy); placement (boundary-only validation) is owned by dev-architecture §4.
dev-backend delegates here for policy and verification depth.
dev-frontend remains responsible for UI implementation, but frontend security touchpoints such as CSP compliance, CORS behavior, XSS prevention, and dependency auditing are defined here.
C0/C1 work (small local patches): See dev §0.0 Work Classifier + §0.1 Patch Fast-Path before reading references.
When to Activate
Activate this skill when you are:
Writing auth, session, cookie, token, password-reset, or OAuth logic.
Accepting user input from forms, URLs, headers, cookies, webhooks, file uploads, rich text, or AI prompts.
Handling secrets, credentials, certificates, encryption keys, or third-party API keys.
Reviewing code for security regressions or production-readiness.
Auditing dependencies, CI pipelines, or release integrity.
One user, one tenant, one environment, all customers, all secrets, all build artifacts.
Security-sensitive changes must name the trust boundary before coding:
Browser ↔ API
Public API ↔ internal service
App ↔ database
Agent prompt ↔ tool execution
CI runner ↔ production artifact
If the change touches auth, payment, file upload, logging, or PII, write the must-pass checks before coding.
This skill owns security policy.
Domain skills own architecture and implementation details.
Modular References
File
When to Read
What It Covers
references/owasp-top10.md
Any security-sensitive code
OWASP Top 10:2025 with unsafe/safe code pairs and checklists. 2025-delta mode: explicitly check A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions, and SSRF folded into A01 Broken Access Control
references/language-quirks.md
When coding in JS/TS, Python, SQL, or Go
Per-language pitfalls that scanners and reviewers commonly miss
For current CVEs, advisories, package maintainer/source checks, release
integrity claims, or registry trust changes, read the active search skill and
follow its query-rewrite, original-source fetch, and evidence-status rules.
Read only the references relevant to the current task.
A small CSS change needs no OWASP reference.
Auth, data access, secrets, file uploads, webhooks, or incident response changes do.
1. Input Validation
Input validation is the first line of defense.
Validate at the first trusted boundary, reject unknown fields, enforce limits, and escape or sanitize on output for the target context.
Client-side validation improves UX only — it is never a security boundary.
Required rules
Validate shape, type, format, enum membership, length, and numeric range.
Reject unknown fields by default.
Canonicalize before validation when encoding differences matter.
Distinguish parsing failures from authorization failures.
Sanitize HTML only when rich text is explicitly allowed.
Re-validate on the server even when frontend uses the same schema.
Validate all input at trust boundaries with schema validation (Zod strict, Pydantic extra="forbid", or equivalent). Reject unknown fields. For injection cases, rich text, and output encoding, read references/owasp-top10.md A05 and references/language-quirks.md.
2. Authentication Checklist
Use this checklist for login, session, token, password reset, magic link, OAuth, and admin access:
Passwords hashed with argon2id (preferred); scrypt next if unavailable; bcrypt mainly for legacy; PBKDF2 only for FIPS-140 contexts. MD5/SHA1/raw SHA256 never for passwords. (OWASP Password Storage ordering, checked 2026-07-02.)
Access tokens are short-lived with reduced scope (RFC 9700). Exact TTLs are risk-based org policy — 15-60 minutes is a common starting range, not a standard-mandated number; cite your policy source.
Refresh tokens rotate on use and support family invalidation after reuse detection.
Browser tokens live in httpOnly, secure, sameSite cookies; keep session tokens out of localStorage.
Sensitive actions such as email change, MFA reset, payout change, and password change require step-up auth.
Failed logins are rate-limited and delayed progressively.
Session invalidation runs after password reset, password change, and privilege change.
Password reset tokens are one-time, short-lived, and stored hashed server-side.
Auth errors are generic — avoid revealing whether a specific email exists.
See references/owasp-top10.md A07 for implementation patterns.
See references/asvs-checklist.md V2 and V3 before deploy.
3. Authorization and Sensitive Flows
Authentication says who the caller is.
Authorization says what the caller may do.
Security failures happen when a route checks only the first.
Required rules
Default deny.
Enforce RBAC or ABAC before business logic.
Perform ownership checks on every resource read and write.
Scope queries by tenant and actor, not only by route.
Re-check authorization on bulk actions, background jobs, exports, and webhooks.
Keep internal flags, role names, and hidden fields out of response serializers.
See references/owasp-top10.md A01 for code pairs.
See dev-backend/SKILL.md §4 for middleware execution order.
4. Secrets Management
Secrets are values that grant access, identity, or decryption capability.
Treat API keys, database credentials, signing keys, OAuth client secrets, webhook secrets, certificates, and recovery codes as secrets.
Rule
Required Practice
Source control
Commit .env.example, never commit .env, real keys, tokens, or private certs
Local development
Load secrets from environment variables or a local secret store
Production
Use Vault, cloud secret manager, or KMS-backed delivery
Rotation
Document owner, rotation cadence, and emergency revocation path
Logging
Redact secrets before logs, traces, analytics, error reports, and screenshots
Testing
Use dedicated non-production keys with least privilege
If a repository change touches secrets, run gitleaks before claiming done.
If a feature adds webhook verification or JWT signing, treat key rollover as part of the feature.
For scanning recipes, read references/static-analysis.md.
For agent workflows and exfiltration risk, read references/agentic-ai-security.md.
5. Security Headers
This skill owns header policy values.
dev-backend owns middleware ordering and integration points.
Content-Security-Policy with explicit default-src, script-src, style-src, img-src, connect-src, frame-ancestors, and base-uri
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy with unused capabilities disabled
X-Frame-Options: DENY when CSP frame-ancestors is not sufficient for legacy support
Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy where required by the app
Apply these via the framework's standard header middleware (Helmet for Express, equivalents elsewhere). Exact directive values are environment-specific — CSP especially must be designed around the app's real script/style/asset/connect origins, not copied from a template.
Frontend touchpoints that must stay aligned
CSP compliance: no inline scripts, no unsafe event handlers, no surprise third-party script injection.
CORS: explicit origin allowlist and correct credential mode for cookie-based auth.
Avoid dangerouslySetInnerHTML unless sanitized with a maintained sanitizer and defended by CSP.
Prefer cookies over browser storage for session tokens.
See references/owasp-top10.md A02 and A05.
See dev-frontend/SKILL.md §§5-7 for performance and accessibility guardrails that still apply after security changes.
6. Rate Limiting
Apply rate limiting per IP and, where available, per user, tenant, and credential target.
Return 429 Too Many Requests with Retry-After.
Log repeated abuse without logging secrets or raw PII.
Treat the limits below as risk-based starting defaults, not fixed gates — tune them to real traffic, abuse risk, and threat model.
Surface
Default starting limit
Login
~5 requests per minute per IP and account identifier
Password reset request
~3 requests per hour per account identifier
Registration
~10 requests per hour per IP
MFA verification
~10 requests per 10 minutes per session
Public API
~100 requests per minute per user or API key
File upload start
~20 requests per hour per user
Webhook verification failures
Alert after burst anomalies and repeated signature failures
Rate limiting is not only for brute force.
Use it for enumeration, abuse, accidental loops, webhook replay storms, and AI-triggered runaway automation.
AI-recommended package names are a supply-chain attack surface: 2025 research found
~20% of LLM-recommended packages in study settings did not exist, and hallucinated
names recur — attackers register them (slopsquatting). Before adding ANY dependency
suggested by an AI (including your own suggestions):
Package exists on the official registry with real release history (not days old)
Maintainer/org and linked source repository are plausible and consistent
No install scripts doing network/exec surprises; lockfile diff reviewed
Provenance/trusted publishing attestation when the registry supports it (npm/PyPI)
Cross-refs: reviewer-side check in dev-code-reviewer §7; registry vetting depth in
references/supply-chain-sbom.md.
7. Static Analysis Integration
Security claims are incomplete without automated checks.
At minimum, run the project-native SAST, dependency-audit, and secret-scan tools (e.g. npm audit/pip-audit, semgrep, gitleaks) in local development and CI. Use whatever the repo already standardizes on; exact commands belong in repo docs.
For CI templates, pre-commit hooks, and tool-specific guidance, read references/static-analysis.md.
For review gating, combine this with dev-code-reviewer/SKILL.md §§1-2.
8. Agent Configuration Security
Agent-authored configuration files create a trust surface distinct from application code.
