/cg-security-hardening

name: cg-security-hardening
description: Harden an indie-scale production app against common attacks — rate limiting, CORS, security headers, input validation, secrets management, authentication, and dependency scanning. Use when the user mentions security, hardening, rate limit, CORS, CSRF, XSS, injection, auth, JWT, secrets, environment variables, dependency vulnerabilities, OWASP, "is my app secure", "how do I prevent", or is about to ship to production. Aligned with OWASP Top 10 2025. NOT for penetration testing, red team exercises, compliance audits (SOC2/HIPAA/PCI), or enterprise WAF configuration.

cg-security-hardening

Close the most common attack surfaces on an indie-scale production web app. Targets solo devs and small teams who do not have a dedicated security engineer, aligned with OWASP Top 10 2025 priorities. The goal is to raise the cost of attack from "trivial" to "not worth the effort" — not to achieve enterprise-grade security posture.

Scope

**This skill covers:**

• Rate limiting (global and endpoint-specific)
• CORS configuration (without breaking your own frontend)
• Security headers (HSTS, CSP, X-Frame-Options, etc.)
• Input validation and output encoding
• Secrets management (env vars, rotation, what to never commit)
• Authentication patterns (passwords, sessions, JWT, MFA)
• Authorization patterns (IDOR prevention, least privilege)
• Dependency scanning and supply chain hygiene
• Error handling that does not leak internal details
• Security logging (what to log, what to never log)
• Safe file upload handling
• SQL injection and XSS prevention

**This skill does NOT cover:**

• Penetration testing or red team exercises (use a pentester)
• Compliance audits (SOC2, HIPAA, PCI-DSS, GDPR legal advice)
• Enterprise WAF configuration (Cloudflare/Akamai/AWS WAF beyond basic setup)
• Full SAST/DAST pipeline integration (separate CI/CD concern)
• Security incident response playbooks
• Bug bounty program setup
• Cryptographic protocol design (use vetted libraries, don't invent)
• Supply chain attack forensics

If the user needs any of the excluded items, recommend specialized tools or services instead of attempting them with this skill.

Required context — gather before generating anything

MUST have answers to these before producing code or config. Ask the user directly if unclear.

1. **What language/framework is the app?** — affects library choices:

• Go → `chi` or `gin` middleware, `validator` for input, `golang-jwt`
• Node.js → `helmet`, `express-rate-limit`, `cors`, `zod`/`joi` for validation
• Python → `Flask-Limiter`/`slowapi`, `pydantic` for validation, `secure` for headers
• Rust → `tower-http` middleware, `validator` crate
• Java / Spring Boot → Spring Security, Bucket4j for rate limiting, Bean Validation (JSR-380)
• .NET → built-in `AspNetCoreRateLimit`, `FluentValidation`, `Microsoft.AspNetCore.Authentication.JwtBearer`

2. **What does the app expose?**

• Public HTML pages with forms (traditional web app)
• Public API consumed by a frontend SPA (CORS matters)
• Public API consumed by mobile apps (CORS irrelevant, auth critical)
• Internal API only (different threat model, still needs hardening)
• Mix of the above

3. **What authentication model?**

• Session cookies (traditional web app)
• JWT bearer tokens (SPA/mobile)
• OAuth via provider (Google, GitHub, Apple)
• API keys (service-to-service)
• None yet (the user may be at "I just shipped it" stage)

4. **Is there user-generated content?**

• File uploads? → sandbox, type validation, size limits, virus scan
• Rich text / markdown? → sanitization library needed
• Plain text only? → simpler threat model

5. **Is the app already in production, or pre-launch?**

• Pre-launch → ideal time for full hardening, no breaking changes
• In production → incremental hardening, measure each change, avoid breaking active users

6. **What's the threat model?** (ask explicitly if unclear)

• Random bots and script kiddies → baseline hardening is enough
• Targeted attacks from motivated actors → need deeper review, maybe a pentester
• Sensitive data (PII, health, financial) → compliance concerns, needs legal review too

The seven pillars of indie-scale hardening

Ordered by impact-to-effort ratio. Start from pillar 1. Do not skip to pillar 7 before pillars 1-3 are done.

Pillar 1 — Rate limiting (stops the most common attacks cheaply)

**Why first**: Credential stuffing, brute force, enumeration, and scraping all rely on high request volume. Rate limiting stops 90% of opportunistic attacks with a single middleware.

**Rules**:

• **MUST** rate limit every authentication endpoint (`/login`, `/signup`, `/password-reset`, `/verify-email`, `/mfa-challenge`) — stricter than everything else
• **MUST** have a global default rate limit on all endpoints
• **SHOULD** have stricter limits on expensive operations (search, export, file upload, AI calls)
• **SHOULD** return `429 Too Many Requests` with `Retry-After` header, not silently drop
• **SHOULD** include `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` headers on every response
• **SHOULD** rate limit by authenticated user ID when available, falling back to IP for anonymous requests
• **MUST NOT** rely on client IP alone behind a reverse proxy without reading `X-Forwarded-For` correctly
• **MUST NOT** set limits so tight that legitimate users hit them (start loose, tighten with real data)
• **SHOULD** prefer sliding window or token bucket algorithms over fixed windows — fixed windows allow burst-at-boundary attacks (e.g., 100 requests at 0:59 + 100 at 1:00 = 200 in 2 seconds)

**Baseline limits** (adjust per app): | Endpoint type | Limit | |---|---| | Login / signup | 5 per minute per IP, 10 per hour per IP | | Password reset request | 3 per hour per email | | General API (authenticated) | 100 per minute per user | | General API (anonymous) | 30 per minute per IP | | Expensive