Security Hardening

Security Hardening

This skill enforces structured security analysis before code reaches production. It covers the most common vulnerabilities found in backend systems and provides concrete mitigation patterns per category.

When to Use

• Any backend feature that handles user input, file uploads, or external data
• Any task involving authentication, authorization, sessions, or tokens
• Code review with a security focus (/review + security scope)
• Before deploying a new API endpoint, service, or integration to production
• When the codebase is new and no security baseline has been established

When NOT to Use

• Pure frontend UI tasks with no backend interaction
• Infrastructure configuration reviewed separately under a dedicated infra checklist
• Internal tooling with no external network exposure and no user data

Core Principle

Assume breach at every boundary. Every input is hostile, every token is potentially stolen, every dependency is potentially compromised. Security is not a final step — it is a constraint on every design decision.

Security Hardening Process

Use the checklist below and track progress:

Security hardening progress:
- [ ] Step 1: Inventory trust boundaries and data flows
- [ ] Step 2: Audit authentication and authorization
- [ ] Step 3: Validate input handling and injection surface
- [ ] Step 4: Review secrets and credential management
- [ ] Step 5: Check security headers and transport
- [ ] Step 6: Verify dependency and supply chain hygiene
- [ ] Step 7: Produce Security Review output

Step 1: Inventory trust boundaries and data flows

Map every point where untrusted data enters the system:

• HTTP request bodies, query params, headers, cookies
• File upload content and filenames
• Webhook payloads from third parties
• Data read from external APIs or message queues
• Data read from the database that originated from user input

For each entry point, verify: who validates it, where, and how failures are handled.

Step 2: Audit authentication and authorization

Authentication (who are you):

• Token signatures verified cryptographically, not just decoded
• Token expiry (exp) checked explicitly
• Refresh token rotation implemented if long-lived sessions exist
• No credentials stored in localStorage — use httpOnly cookies or server-side sessions

Authorization (what are you allowed to do):

• Every route/handler has an explicit authorization check — no implicit "logged in = allowed"
• Object-level authorization: user A cannot access user B's resources by changing an ID
• Function-level authorization: low-privilege users cannot call admin endpoints by knowing the URL
• Authorization checked server-side, never trusted from client payload

Step 3: Validate input handling and injection surface

Injection (OWASP A03):

• SQL: use parameterized queries or ORM exclusively — no string concatenation into SQL
• Command injection: never pass user input to exec, shell, spawn without strict allowlist
• Path traversal: normalize and validate file paths, reject ../ sequences, use path.resolve + boundary check
• SSRF: if accepting URLs from users, validate against an allowlist of allowed hosts/schemes

Input validation:

• Validate shape, type, and length at the boundary — before any business logic
• Reject unexpected fields explicitly (strip unknown properties, do not silently pass them)
• Validate file uploads: MIME type (from content inspection, not filename), size limit, extension allowlist

XSS (OWASP A03 — frontend impact):

• Never render user content as raw HTML
• Set Content-Type: application/json explicitly on API responses
• Use Content-Security-Policy header (see Step 5)

Step 4: Review secrets and credential management

• No secrets in source code — no hardcoded API keys, passwords, tokens, or private keys
• No secrets in environment variable names that reveal their value (avoid DB_PASSWORD=prod123)
• Secrets loaded from environment or a secrets manager (Vault, AWS Secrets Manager, Doppler)
• .env files in .gitignore — verified, not assumed
• CI/CD secrets injected at runtime, not stored in repo or build artifacts
• JWT signing keys rotatable without service downtime
• Database passwords rotatable — connection pools handle graceful reconnection

Audit pattern: search for password, secret, key, token, api_key literals in source and committed config files.

Step 5: Check security headers and transport

Every HTTP response must include:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()

CORS:

• Access-Control-Allow-Origin must not be * for authenticated endpoints
• Allowed origins must be an explicit allowlist, not a regex match on user-controlled values
• Credentials (withCredentials: true) require explicit Access-Control-Allow-Credentials: true and a non-wildcard origin

Rate limiting:

• Authentication endpoints (login, register, password reset) must have rate limits
• Expensive compute or data endpoints must have rate limits
• Rate limits applied per IP and per user ID when authenticated

Step 6: Verify dependency and supply chain hygiene

• Run npm audit, pip audit, or cargo audit — zero high/critical CVEs before deployment
• Lockfile committed and pinned — no floating ^ ranges in production without lockfile
• Dependency count minimized — remove unused packages
• Docker base images pinned to digest or minor version, not latest
• No eval, Function(), or dynamic code execution from user-controlled strings

Step 7: Produce Security Review output

## Security Review — [service/feature] — [date]

### Trust Boundaries
[Enumerated entry points and data flows]

### Findings
| Severity | Category | Location | Issue | Mitigation |
|---|---|---|---|---|
| CRITICAL | Injection | auth/login.ts:42 | Raw SQL concatenation | Use parameterized query |
| HIGH | AuthZ | api/documents.ts | Missing object-level auth | Add ownership check |
| MEDIUM | Secrets | .env.example | Real credentials committed | Rotate + remove |
| LOW | Headers | middleware/cors.ts | Wildcard CORS on auth routes | Restrict to allowlist |

### Verified Clean
[Areas reviewed and confirmed free of issues]

### Deferred
[Known issues accepted with documented reason and owner]

Severity definitions:

• CRITICAL: exploitable without authentication, leads to data breach or full compromise
• HIGH: exploitable by authenticated users, significant data exposure or privilege escalation
• MEDIUM: requires specific conditions, limited impact
• LOW: defense-in-depth improvement, no direct exploitability

Security Review Checklist

Authentication:
- [ ] Tokens verified cryptographically (signature + expiry)
- [ ] No credentials in localStorage
- [ ] Refresh token rotation implemented

Authorization:
- [ ] Every endpoint has explicit authZ check
- [ ] Object-level: user cannot access other users' resources
- [ ] Function-level: privilege escalation by URL is impossible

Input:
- [ ] All external input validated at entry boundary
- [ ] SQL uses parameterized queries exclusively
- [ ] File uploads validated by content, not filename
- [ ] No path traversal possible

Secrets:
- [ ] No secrets in source code or committed config
- [ ] .env in .gitignore — confirmed
- [ ] CI secrets injected at runtime

Transport:
- [ ] Security headers present on all responses
- [ ] CORS allowlist is explicit, not wildcard on authenticated routes
- [ ] Rate limiting on auth endpoints

Dependencies:
- [ ] npm/pip/cargo audit passes with no high/critical CVEs
- [ ] Lockfile committed and up to date

OWASP Top 10 Quick Reference

Anti-Patterns to Avoid

Connected Skills

• code-review — run security-hardening as part of every backend code review
• api-contract — API design decisions (auth scheme, input validation contract) are security decisions
• technical-context-discovery — discover existing security patterns before introducing new ones
• nestjs — NestJS-specific guards, interceptors, and validation pipe patterns
• python-fastapi — FastAPI-specific dependency injection for auth and exception handlers
• sql-and-database — parameterized queries, least-privilege DB users, migration safety