/shared-security-auth-security

name: shared-security-auth-security
description: Secrets management, XSS prevention, CSRF protection, dependency scanning, DOMPurify sanitization, CSP headers, CODEOWNERS, HttpOnly cookies

Security Patterns

> **Quick Guide:** Managing secrets? Use .env.local (gitignored), CI secrets, rotate on compromise or team changes. Dependency security? Enable automated scanning (Dependabot), patch critical vulns within 24hrs. XSS prevention? Modern frameworks auto-escape output by default - never bypass with raw HTML injection unless sanitized with DOMPurify. Set CSP headers. CODEOWNERS? Require security team review for auth/, .env.example, workflows.

**Detailed Resources:**

• For code examples, see [examples/core.md](examples/core.md) (essential patterns)
• For decision frameworks and anti-patterns, see [reference.md](reference.md)

**Additional Examples:**

• [examples/xss-prevention.md](examples/xss-prevention.md) - XSS protection, DOMPurify, CSP headers
• [examples/dependency-security.md](examples/dependency-security.md) - Dependabot, CI security checks
• [examples/access-control.md](examples/access-control.md) - CODEOWNERS, rate limiting, branch protection

---

<critical_requirements>

CRITICAL: Before Using This Skill

**(You MUST NEVER commit secrets to the repository - use .env.local and CI secrets only)**

**(You MUST sanitize ALL user input before rendering raw HTML - use DOMPurify before any HTML injection)**

**(You MUST patch critical/high vulnerabilities within 24 hours - use Dependabot for automated scanning)**

**(You MUST use HttpOnly cookies for authentication tokens - NEVER localStorage or sessionStorage)**

**(You MUST configure CODEOWNERS for security-sensitive files - require security team approval)**

</critical_requirements>

---

**Auto-detection:** security, secrets management, XSS prevention, CSRF protection, Dependabot, vulnerability scanning, authentication, DOMPurify, CSP headers, CODEOWNERS, HttpOnly cookies

**When to use:**

• Managing secrets securely (never commit, use .env.local and CI secrets)
• Setting up Dependabot for automated vulnerability scanning
• Preventing XSS attacks (framework auto-escaping, DOMPurify, CSP headers)
• Configuring CODEOWNERS for security-sensitive code
• Implementing secure authentication and token storage

**When NOT to use:**

• For general code quality reviews (not a security concern)
• For performance optimization (different domain)
• For CI/CD pipeline setup (security patterns here are for code, not infrastructure)
• When security review would delay critical hotfixes (document for follow-up)

**Key patterns covered:**

• Never commit secrets (.gitignore, CI secrets, rotation policies quarterly)
• Automated dependency scanning with Dependabot (critical within 24h)
• XSS prevention (framework auto-escaping, DOMPurify for HTML, CSP headers)
• CSRF protection with tokens and SameSite cookies
• CODEOWNERS for security-sensitive areas (.env.example, auth code, workflows)
• Secure token storage (HttpOnly cookies, in-memory access tokens)

---

<philosophy>

Philosophy

Security is not a feature - it's a foundation. Every line of code must be written with security in mind. Defense in depth means multiple layers of protection, so if one fails, others catch the attack.

**When to use security patterns:**

• Always - security is not optional
• When handling user input (sanitize and validate)
• When managing secrets (environment variables, rotation)
• When storing authentication tokens (HttpOnly cookies)
• When setting up CI/CD (vulnerability scanning, CODEOWNERS)

**When NOT to compromise:**

• Never skip HTTPS in production
• Never trust client-side validation alone
• Never commit secrets to repository
• Never use localStorage for sensitive tokens
• Never bypass security reviews for critical code

**Core principles:**

• **Least privilege**: Grant minimum necessary access
• **Defense in depth**: Multiple layers of security
• **Fail securely**: Default to deny, not allow
• **Don't trust user input**: Always validate and sanitize
• **Assume breach**: Plan for when (not if) attacks happen

</philosophy>

---

<patterns>

Core Patterns

Pattern 1: Secret Management

Never commit secrets to the repository. Use environment variables in .env.local (gitignored) for development, and CI/CD secret managers for production. Rotate secrets quarterly or on team member departure.

What Are Secrets

Secrets include: API keys, tokens, passwords, database credentials, private keys, certificates, OAuth client secrets, encryption keys, JWT secrets.

Where to Store Secrets

**Development:**

• `.env.local` (gitignored)
• Per-developer local overrides
• Never committed to repository

**CI/CD:**

• GitHub Secrets
• Vercel Environment Variables
• GitLab CI/CD Variables
• Other platform secret managers

**Production:**

• Environment variables (injected by platform)
• Secret management services (AWS Secrets Manager, HashiCorp Vault)
• Never hardcoded in code

Rotation Policies

**Note:** NIST SP 800-63-4 (2025) recommends against mandatory periodic password rotation for users. Instead, use event-based rotation (on compromise, team member departure, or security incident). Periodic rotation is still recommended for service accounts and privileged access.

| Secret Type | Rotation Frequency | | ---------------------------- | --------------------------------------- | | Service account credentials | 90 days (quarterly) | | API keys | 365 days (annually) or on compromise | | User passwords | On compromise only (NIST 2025 guidance) | | Privileged account passwords | 90 days (quarterly) | | Certificates | 30 days warning before expiry | | All secrets | Immediately on team member departure |

**See [examples/core.md](examples/core.md#pattern-1-secret-management) for code ex