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,

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 A04: 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 OWASP Top 10 Prevention Patterns These are prevention patterns, not a ranking. For the 2021 ordering, see the quick reference table in ../../references/security checklist.md . Injection (SQL, NoSQL, OS Command) Broken Authentication Cross Site Scripting (XSS) Broken Access Control Security Misconfiguration Sensitive Data Exposure Server Side Request Forgery (SSRF) Any time the server fetches a URL the user influenced — webhooks, "import from URL", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, localhost , private IPs). The range() !== 'unicast' check covers loopback, link local 169.254.169.254 (cloud metadata, the 1 SSRF target), private, and unique local ranges across IPv4 and IPv6. Caveat — this still has a TOCTOU gap. fetch resolves DNS again after the check, so an attacker using a short TTL record can rebind to an internal IP between validation and connection. For high risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front ( request filtering agent / ssrf req filter ). Input Validation Patterns Schema Validation at Boundaries File Upload Safety Destructive Operations on Derived Paths A delete, move, or overwrite is only as safe as the value that names its target. Reading that value from the kernel, a job payload, or a sibling service proves where it arrived from , not who wrote it — another process's command line is as attacker controlled as a form field. A shape check ("absolute path, at least one directory deep") proves well formedness and gets mistaken for authorization; that is how a cleanup routine deletes the root instead of the leaf. Before a destructive call, require all three: the resolved target sits under an allowlisted root (compare after resolving symlinks, never on the raw string); it is at least one level below that root, so a root is never itself the target; and it carries evidence that it is yours , read before the operation and before any teardown that removes it — otherwise "absent" and "not mine" are indistinguishable. On refusal, log the rejected target and stop: a cleanup that falls back to a broader default path is the failure this guards against. Worked example in ../../references/security checklist.md . Two limits, because the check reads stronger than it is. A marker inside the tree is self attestation — anything that can write there can write the marker — so the expected owner has to come from authenticated state, and the marker needs integrity protection (restrictive ownership, or a MAC) before it counts as authorization. And resolving a path and then operating on the name is a check/use race wherever an untrusted process can swap an ancestor: on a shared volume, hold the target by descriptor and use no follow, beneath the root operations, or make sure the hierarchy cannot change for the duration. Triaging Dependency Audit Results Package manager audits report known advisories; they do not prove a package is trustworthy or that vulnerable code is reachable. Use this decision tree: Key questions: Is the vulnerable function actually called in your code path? Is the dependency a runtime dependency or dev only? Is the vulnerability exploitable given your deployment context (e.g., a server side vulnerability in a client only app)? When you defer a fix, document the reason and set a review date. Supply Chain Hygiene Do not assume npm or treat the nearest manifest as the install root. Apply this order: 1. Find the installation boundary and manager. Use the workspace root that owns the lockfile, or an independent nested project only when it is outside that workspace. There, corroborate packageManager (when present), the lockfile, and CI; stop on disagreement or competing lockfiles. Pin the manager version and use the matrix in ../../references/security checklist.md . 2. Block dependency scripts before first execution. Bootstrap with scripts disabled or a documented fail closed policy, inspect the pending script source, approve only the minimum required packages, commit the policy, then verify with a clean frozen/immutable install. Never blanket approve scripts. Audits only find known advisories; they do not catch a newly malicious or typosquatted package. Therefore: Never apply forced audit remediation automatically ( npm audit fix force or equivalent). Preview the remediation, read changelogs, and test each resulting upgrade; forced fixes may cross declared dependency ranges. Verify registry signatures and provenance where supported ( npm audit signatures , pnpm audit signatures ) and treat absence as a signal to investigate, not automatic proof of compromise. Review new dependencies, lockfile diffs, and script policy changes together — ownership, maintenance, release age, provenance, transitive graph, and typosquats such as cross env vs crossenv (OWASP A06 , LLM03 ). Rate Limiting Count in a shared store once there is more than one process. express rate limit keeps its counters in process memory by default. Behind a load balancer each instance holds its own count, so the effective limit is max × instances ; on serverless or edge runtimes a fresh invocation starts from zero, so the auth limit above may never fire. Pass a shared store (Redis via rate limit redis ), or use an HTTP based limiter that works where a long lived TCP connection does not (for example @upstash/ratelimit ): Secrets Management Always check before committing: If a secret is ever committed, rotate it. Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history. Data Privacy & Compliance Securing data is "can an attacker read it?" Privacy is "should we even hold it, and for how long?" — a separate question that hardening doesn't answer. The cheapest data to protect, breach, and comply over is the data you never collected. Treat personal data as a liability to minimize, not an asset to hoard. Know what you hold. You can't protect or honor a deletion request for data you can't find. Classify fields as you add them: Class Examples Handling Non personal Aggregates, anonymized counts Normal handling Personal (PII) Name, email, IP, device/user IDs Minimize, access control, include in export/delete Sensitive Health, finance, location, biometrics, gov IDs, anything about minors Extra basis to collect, stricter access, often encryption + audit logging Operating rules: Minimize and set a purpose. Collect a field only against a stated use. "It might be useful later" is not a purpose — it's latent breach scope. Don't log PII into telemetry (the observability and instrumentation skill makes the same point from the ops side). Set retention up front, then actually delete. Every personal data store needs a TTL and a working deletion path — including backups, caches, search indexes, and analytics copies. Data with no expiry is a breach scheduled for later. Support the data subject rights your jurisdiction requires (GDPR/CCPA and kin): export, correct, and delete on request. These are engineering features — design the schema so a user's data is findable and erasable , not smeared irreversibly across systems. Get consent before collection or third party sharing , and make it auditable. Sending PII to an analytics/ad/LLM vendor is "sharing" — the user's choice gates it, and the vendor needs a data processing agreement. Localize defaults, don't hardcode one region's law. Data residency and rules differ by user location; make the policy a configurable boundary, not an assumption. When data crosses a trust boundary, validate it as untrusted (see Input Validation above); when a privacy incident exposes personal data, the breach notification clock is part of the postmortem — follow the debugging and error recovery skill. Securing AI / LLM Features If your app calls an LLM — chatbots, summarizers, agents, RAG — i

security-and-hardening