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.
\nControls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:
\n| Threat | \nAsk | \nTypical mitigation | \n
|---|---|---|
| Spoofing | \nCan someone impersonate a user/service? | \nAuthentication, signature verification | \n
| Tampering | \nCan data be altered in transit or at rest? | \nIntegrity checks, parameterized queries, HTTPS | \n
| Repudiation | \nCan an action be denied later? | \nAudit logging of security events | \n
| Information disclosure | \nCan data leak? | \nEncryption, field allowlists, generic errors | \n
| Denial of service | \nCan it be overwhelmed? | \nRate limiting, input size caps, timeouts | \n
| Elevation of privilege | \nCan a user gain rights they shouldn't? | \nAuthorization checks, least privilege | \n
If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP A04: Insecure Design — most breaches begin in design, not code.
\neval() or innerHTML with user-provided dataThe rules below are the workflow; a concrete implementation of each lives in references/hardening-patterns.md. Open the section you need when you reach that code, not before.
\nPatterns: Injection, XSS, Access control.
\nhttpOnly, secure, and sameSite: 'lax' or 'strict' (the CSRF defense; 'none' sends the cookie on cross-site requests), with a bounded maxAge.Pattern: Authentication.
\ndefault-src 'self' and is tightened, not loosened.* with credentials.passwordHash, reset tokens) before any response. Error bodies are generic; internals go to server logs only.Patterns: Misconfiguration, Sensitive data exposure.
\nPatterns: Schema validation, File upload.
\nAny URL the user influences — webhooks, import-from-URL, image proxies, link previews — can be aimed at internal services. Allowlist scheme and host, resolve all DNS records and reject any private or reserved address (loopback, link-local 169.254.169.254, private, unique-local, for IPv4 and IPv6), and forbid redirects. That check still has a DNS-rebinding TOCTOU gap: for high-risk surfaces, pin the resolved IP or put a filtering agent in front.
Pattern: SSRF.
\nA delete, move, or overwrite is only as safe as the value naming its target, and trust follows who wrote that value, not which channel delivered it: another process's command line is as attacker-controlled as a form field. A shape check proves well-formedness, not authorization. Before the call, require all three: the resolved target (symlinks resolved) sits under an allowlisted root; it is at least one level below that root; and it carries ownership evidence read before the operation. On refusal, log the rejected target and stop; never fall back to a broader default path.
\nWhy the check is weaker than it reads (marker self-attestation, check/use races): Destructive paths. Worked code: ../../references/security-checklist.md.
Limit the API generally and auth endpoints strictly (about 10 attempts per 15 minutes). Once more than one process serves traffic, in-memory counters silently become max × instances, or never fire on serverless: back the limiter with a shared store.
Pattern: Rate limiting.
\nSecrets come from the environment. .env.example is committed with placeholders; real .env* files and key material are gitignored; grep the staged diff before committing. A secret that reaches a remote is compromised the moment it lands: rotate it first, then purge history.
Pattern: Secrets management.
\npackageManager (when present), the lockfile, and CI; stop on disagreement or competing lockfiles. Pin the manager version.npm audit fix --force or equivalent) automatically, since forced fixes may cross declared dependency ranges; preview, read changelogs, test each upgrade. Document every deferral with a reason and a review date.cross-env vs crossenv). Review new dependencies, lockfile diffs, and script-policy changes together: ownership, maintenance, release age, provenance, transitive graph. Verify registry signatures where supported (npm audit signatures, pnpm audit signatures) and treat their absence as a signal to investigate, not automatic proof of compromise (A06, LLM03).Triage decision tree: Dependency audit triage. Manager matrix and install-script gate: ../../references/security-checklist.md.
Hardening asks \"can an attacker read it?\" Privacy asks \"should we hold it at all, and for how long?\" The cheapest data to protect, breach, and comply over is the data you never collected; treat personal data as a liability to minimize.
\nobservability-and-instrumentation skill makes the same point from the ops side).Classification table: Data classification. A privacy incident starts the breach-notification clock; run the postmortem with the debugging-and-error-recovery skill.
Calling an LLM — chatbots, summarizers, agents, RAG — adds a new attack surface; map it to the OWASP Top 10 for LLM Applications (2025):
\neval, SQL, a shell, innerHTML, or a file path; parse defensively, validate against a schema, then encode.Pattern: LLM output handling.
\nBefore sign-off, walk ../../references/security-checklist.md: it covers authentication, authorization, input, data protection and privacy, headers and CORS, dependencies and supply chain, AI/LLM, and error handling, plus the OWASP quick-reference tables.
| Rationalization | \nReality | \n
|---|---|
| \"This is an internal tool, security doesn't matter\" | \nInternal tools get compromised. Attackers target the weakest link. | \n
| \"We'll add security later\" | \nSecurity retrofitting is 10x harder than building it in. Add it now. | \n
| \"No one would try to exploit this\" | \nAutomated scanners will find it. Security by obscurity is not security. | \n
| \"The framework handles security\" | \nFrameworks provide tools, not guarantees. You still need to use them correctly. | \n
| \"It's just a prototype\" | \nPrototypes become production. Security habits from day one. | \n
| \"Threat modeling is overkill here\" | \nFive minutes of \"how would I attack this?\" prevents the design flaws no control can patch later. | \n
| \"It's just LLM output, it's only text\" | \nThat \"text\" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input. | \n
| \"The audit passed, so the dependency is safe\" | \nAudits match known advisories. They do not detect a newly malicious package or make unreviewed install scripts safe to execute. | \n
| \"Collect it now, we might need it later\" | \nData you don't hold can't be breached, subpoenaed, or mis-deleted. \"Might need it\" is breach scope, not a purpose. | \n
| \"We'll handle deletion requests manually\" | \nManual erasure misses backups, caches, and analytics copies. If the schema can't find a user's data, you can't honor the request — design for it. | \n
| \"Compliance is legal's problem, not ours\" | \nExport, deletion, retention, and consent are schema and code. Legal can't bolt them on after you've smeared PII across ten systems. | \n
*) originsevalAfter implementing security-relevant code:
\n