/security-and-hardening

name: security-and-hardening
description: Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions or session cookies, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved.

Security and Hardening

Overview

Security-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.

When to Use

• Building anything that accepts user input
• Implementing authentication or authorization
• Storing or transmitting sensitive data
• Integrating with external APIs or services
• Adding file uploads, webhooks, or callbacks
• Handling payment or PII data

Process: Threat Model First

Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:

1. **Map the trust boundaries.** Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and **LLM output** — plus the local values that look internal because the OS handed them to you: another process's command line or environment, filenames on a shared volume, a path in a job payload. Trust follows who *wrote* a value, not which channel delivered it. Every boundary is attack surface. 2. **Name the assets.** What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement. 3. **Run STRIDE over each boundary** — a quick lens, not a ceremony:

| Threat | Ask | Typical mitigation | |---|---|---| | **S**poofing | Can someone impersonate a user/service? | Authentication, signature verification | | **T**ampering | Can data be altered in transit or at rest? | Integrity checks, parameterized queries, HTTPS | | **R**epudiation | Can an action be denied later? | Audit logging of security events | | **I**nformation disclosure | Can data leak? | Encryption, field allowlists, generic errors | | **D**enial of service | Can it be overwhelmed? | Rate limiting, input size caps, timeouts | | **E**levation of privilege | Can a user gain rights they shouldn't? | Authorization checks, least privilege |

4. **Write abuse cases next to use cases.** For each feature, ask "how would I misuse this?" — then make that your first test.

If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP **A06:2025 Insecure Design** — most breaches begin in design, not code.

The Three-Tier Boundary System

Always Do (No Exceptions)

• **Validate all external input** at the system boundary (API routes, form handlers)
• **Parameterize all database queries** — never concatenate user input into SQL
• **Encode output** to prevent XSS (use framework auto-escaping, don't bypass it)
• **Use HTTPS** for all external communication
• **Hash passwords** with bcrypt/scrypt/argon2 (never store plaintext)
• **Set security headers** (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• **Use httpOnly, secure, sameSite cookies** for sessions
• **Run the detected package manager's native audit** against the committed lockfile before every release

Ask First (Requires Human Approval)

• Adding new authentication flows or changing auth logic
• Storing new categories of sensitive data (PII, payment info)
• Adding new external service integrations
• Changing CORS configuration
• Adding file upload handlers
• Modifying rate limiting or throttling
• Granting elevated permissions or roles

Never Do

• **Never commit secrets** to version control (API keys, passwords, tokens)
• **Never log sensitive data** (passwords, tokens, full credit card numbers)
• **Never trust client-side validation** as a security boundary
• **Never disable security headers** for convenience
• **Never use `eval()` or `innerHTML`** with user-provided data
• **Never store sessions in client-accessible storage** (localStorage for auth tokens)
• **Never expose stack traces** or internal error details to users

Hardening Controls

The rules below are the workflow; a concrete implementation of each lives in [references/hardening-patterns.md](references/hardening-patterns.md). Open the section you need when you reach that code, not before.

Injection, XSS, and access control

• Parameterize every query. Never build SQL, NoSQL, or shell commands from input strings.
• Encode output through the framework's auto-escaping. If raw HTML is unavoidable, sanitize with an allowlist sanitizer first.
• Check **authorization** on every request, not just authentication: the authenticated user must own, or be permitted on, the specific resource (A01:2025, IDOR).

Patterns: [Injection](references/hardening-patterns.md#injection), [XSS](references/hardening-patterns.md#cross-site-scripting-xss), [Access control](references/hardening-patterns.md#broken-access-control).

Authentication and sessions

• Hash passwords with bcrypt (≥12 rounds), scrypt, or argon2. The session secret comes from the environment, never from code.
• Session cookies are `httpOnly`, `secure`, and `sameSite: 'lax'` or `'strict'` (the CSRF defense; `'none'` sends the cookie on cross-site requests), with a bounded `maxAge`.

Pattern: [Authentication](references/hardening-patterns.md#broken-authentication).

Headers, CORS, and responses

• Security headers on every response (helmet or the framework equivalent); CSP starts from `default-src 'self'` and is tightened, not loo