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 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: 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. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement. 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 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) // BAD: SQL injection via string concatenation const query = `SELECT * FROM users WHERE id = ' ${userId} '` ; // GOOD: Parameterized query const user = await db. query ( 'SELECT * FROM users WHERE id = $1' , [userId]); // GOOD: ORM with parameterized input const user = await prisma. user . findUnique ({ where : { id : userId } }); Broken Authentication // Password hashing import { hash, compare } from 'bcrypt' ; const SALT_ROUNDS = 12 ; const hashedPassword = await hash (plaintext, SALT_ROUNDS ); const isValid = await compare (plaintext, hashedPassword); // Session management app. use ( session ({ secret : process. env . SESSION_SECRET , // From environment, not code resave : false , saveUninitialized : false , cookie : { httpOnly : true , // Not accessible via JavaScript secure : true , // HTTPS only sameSite : 'lax' , // CSRF protection maxAge : 24 * 60 * 60 * 1000 , // 24 hours }, })); Cross-Site Scripting (XSS) // BAD: Rendering user input as HTML element. innerHTML = userInput; // GOOD: Use framework auto-escaping (React does this by default) return < div > {userInput} </ div > ; // If you MUST render HTML, sanitize first import DOMPurify from 'dompurify' ; const clean = DOMPurify . sanitize (userInput); Broken Access Control // Always check authorization, not just authentication app. patch ( '/api/tasks/:id' , authenticate, async (req, res) => { const task = await taskService. findById (req. params . id ); // Check that the authenticated user owns this resource if (task. ownerId !== req. user . id ) { return res. status ( 403 ). json ({ error : { code : 'FORBIDDEN' , message : 'Not authorized to modify this task' } }); } // Proceed with update const updated = await taskService. update (req. params . id , req. body ); return res. json (updated); }); Security Misconfiguration // Security headers (use helmet for Express) import helmet from 'helmet' ; app. use ( helmet ()); // Content Security Policy app. use (helmet. contentSecurityPolicy ({ directives : { defaultSrc : [ "'self'" ], scriptSrc : [ "'self'" ], styleSrc : [ "'self'" , "'unsafe-inline'" ], // Tighten if possible imgSrc : [ "'self'" , 'data:' , 'https:' ], connectSrc : [ "'self'" ], }, })); // CORS — restrict to known origins app. use ( cors ({ origin : process. env . ALLOWED_ORIGINS ?. split ( ',' ) || 'http://localhost:3000' , credentials : true , })); Sensitive Data Exposure // Never return sensitive fields in API responses function sanitizeUser ( user : UserRecord ): PublicUser { const { passwordHash, resetToken, ...publicFields } = user; return publicFields; } // Use environment variables for secrets const API_KEY = process. env . STRIPE_API_KEY ; if (! API_KEY ) throw new Error ( 'STRIPE_API_KEY not configured' ); 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). // BAD: fetch whatever the user gives you await fetch (req. body . webhookUrl ); // GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirects import { lookup } from 'node:dns/promises' ; import ipaddr from 'ipaddr.js' ; const ALLOWED_HOSTS = new Set ([ 'hooks.example.com' ]); async function assertSafeUrl ( raw : string ): Promise < URL > { const url = new URL (raw); if (url. protocol !== 'https:' ) throw new Error ( 'https only' ); if (! ALLOWED_HOSTS . has (url. hostname )) throw new Error ( 'host not allowed' ); // Resolve ALL records; a single private/reserved address fails the check. const addrs = await lookup (url. hostname , { all : true }); if (addrs. some ( ( a ) => ipaddr. parse (a. address ). range () !== 'unicast' )) { throw new Error ( 'private/reserved IP' ); } return url; } await fetch ( await assertSafeUrl (req. body . webhookUrl ), { redirect : 'error' }); 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 import { z } from 'zod' ; const CreateTaskSchema = z. object ({ title : z. string (). min ( 1 ). max ( 200 ). trim (), description : z. string (). max ( 2000 ). optional (), priority : z. enum ([ 'low' , 'medium' , 'high' ]). default ( 'medium' ), dueDate : z. string (). datetime (). optional (), }); // Validate at the route handler app. post ( '/api/tasks' , async (req, res) => { const result = CreateTaskSchema . safeParse (req. body ); if (!result. success ) { return res. status ( 422 ). json ({ error : { code : 'VALIDATION_ERROR' , message : 'Invalid input' , details : result. error . flatten (), }, }); } // result.data is now typed and validated const task = await taskService. create (result. data ); return res. status ( 201 ). json (task); }); File Upload Safety // Restrict file types and sizes const ALLOWED_TYPES = [ 'image/jpeg' , 'image/png' , 'image/webp' ]; const MAX_SIZE = 5 * 1024 * 1024 ; // 5MB function validateUpload ( file : UploadedFile ) { if (! ALLOWED_TYPES . includes (file. mimetype )) { throw new ValidationError ( 'File type not allowed' ); } if (file. size > MAX_SIZE ) { throw new ValidationError ( 'File too large (max 5MB)' ); } // Don't trust the file extension — check magic bytes if critical } 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: The native package-manager audit reports a vulnerability ├── Severity: critical or high │ ├── Is the vulnerable code reachable in runtime, build, test, or deployment paths? │ │ ├── YES --> Fix immediately (update, patch, or replace the dependency) │ │ └── NO (confirmed unused across those paths) --> Fix soon, but not a blocker │ └── Is a fix available? │ ├── YES --> Update to the patched version │ └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date ├── Severity: moderate │ ├── Reachable in production? --> Fix in the next release cycle │ └── Dev-only? --> Fix when convenient, track in backlog └── Severity: low └── Track and fix during regular dependency updates 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: 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 . 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 import rateLimit from 'express-rate-limit' ; // General API rate limit app. use ( '/api/' , rateLimit ({ windowMs : 15 * 60 * 1000 , // 15 minutes max : 100 , // 100 requests per window standardHeaders : true , legacyHeaders : false , })); // Stricter limit for auth endpoints app. use ( '/api/auth/' , rateLimit ({ windowMs : 15 * 60 * 1000 , max : 10 , // 10 attempts per 15 minutes })); 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 ): import { Ratelimit } from '@upstash/ratelimit' ; import { Redis } from '@upstash/redis' ; const authLimiter = new Ratelimit ({ redis : Redis . fromEnv (), // UPSTASH_REDIS_REST_URL + _TOKEN limiter : Ratelimit . slidingWindow ( 10 , '15 m' ), // 10 attempts per 15 minutes, across all instances }); const { success } = await authLimiter. limit ( `login: ${req.ip} ` ); if (!success) return res. status ( 429 ). end ();