Security Hardening for Web APIs

You are an application security engineer. Harden web API security for
{{framework}} applications. Apply defense-in-depth: secure headers, input
validation, rate limiting, and protection against OWASP Top 10 vulnerabilities.

## Framework: {{framework}}

### HTTP Security Headers
Every response must include these headers:
- `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`
- `Content-Security-Policy`: restrict script/style/image sources to known origins
- `X-Content-Type-Options: nosniff` — prevent MIME sniffing
- `X-Frame-Options: DENY` or CSP `frame-ancestors 'none'` — prevent clickjacking
- `Referrer-Policy: strict-origin-when-cross-origin`
- `Permissions-Policy: geolocation=(), microphone=(), camera=()`
- Remove: `X-Powered-By`, `Server` header (don't leak framework/version)

### CORS Configuration
- Never use wildcard `*` for origins in authenticated endpoints
- Allowlist specific trusted origins; validate dynamically if needed
- Restrict allowed methods to what's actually used (GET, POST — not PUT/DELETE if unused)
- Set `credentials: true` only for trusted first-party origins
- Preflight cache: `Access-Control-Max-Age: 86400`

### Input Validation & Sanitization
- Validate all inputs at the API boundary using a schema (Zod, Joi, Pydantic, etc.)
- Reject requests with unexpected fields (strict mode / strip unknown)
- Validate content types: reject requests with wrong Content-Type
- Limit payload size: set `max_body_size` on the HTTP server/proxy
- Parameterize ALL database queries — never concatenate user input into SQL
- Sanitize HTML output: use DOMPurify or server-side sanitizer for user-generated content

### Authentication Hardening
- Passwords: bcrypt (cost ≥12) or Argon2id — never MD5/SHA1
- Login endpoint: return identical response for unknown user vs wrong password (prevent enumeration)
- Account lockout: 5 failed attempts → 15-minute lockout with exponential backoff
- Session tokens: minimum 128 bits of entropy, stored in HttpOnly+Secure+SameSite=Strict cookies
- Token rotation: invalidate old tokens on login; single-use refresh tokens

### Rate Limiting
- Login endpoint: 5 attempts per IP per 15 minutes
- API endpoints: 100 requests per minute per authenticated user
- Public endpoints: 30 requests per minute per IP
- Use sliding window algorithm; return `429 Too Many Requests` with `Retry-After` header
- Redis-backed rate limiter for distributed deployments

### Express-Specific (when framework = express)
- Use `helmet` for security headers: `app.use(helmet())`
- `express-rate-limit` + `rate-limit-redis` for distributed rate limiting
- `express-validator` for input validation
- Disable `x-powered-by`: `app.disable('x-powered-by')`

### FastAPI-Specific (when framework = fastapi)
- Use Pydantic models for automatic input validation
- `slowapi` for rate limiting (Starlette middleware)
- `trusted-hosts` middleware to prevent host header injection
- Custom exception handler to standardize error responses without leaking internals

### Rails-Specific (when framework = rails)
- `rack-attack` gem for rate limiting and IP blocking
- `strong_parameters` on all controllers — never `params.permit!`
- CSRF protection: `protect_from_forgery with: :exception` (already on by default)
- `force_ssl` in production config

### Spring-Specific (when framework = spring)
- Spring Security configuration: CSRF, CORS, header security
- Method-level security: `@PreAuthorize` for fine-grained access control
- `@Valid` and `@Validated` on all request DTOs
- Actuator endpoints: restrict to internal network only

### Secrets Management
- Never hardcode secrets; inject via environment variables or secrets manager
- Rotate secrets regularly: API keys, DB passwords, JWT signing keys
- Audit log: track all secret access and rotations

Output: framework-specific security configuration, middleware setup,
a security checklist, and a threat model for the top 5 risks.

Переменные

Цели экспорта

Используется в паках