Security in Depth for Full-Stack Developers

This lesson is the server side of web security for a full-stack developer: the attacks interviewers ask about, a small attack and a small fix for each, and the "boring" controls (password storage, headers, rate limits, secrets, dependencies, uploads, logs) that decide whether an incident is small or large.

The browser side is already covered, so I link to it instead of repeating it. For the frontend checklist (CSP, dangerouslySetInnerHTML, clickjacking, Subresource Integrity) see Browser, Lesson 07. For where tokens live, XSS and CSRF, see Browser, Lesson 03. For login, OAuth, sessions and passkeys, see Full-Stack Q&A, Lesson 22. For authorization basics on the server see Backend, Lesson 06.

Words used in this lesson

• Attack surface is every place where outside data or outside callers can reach your system.
• A trust boundary is a line where data moves from something you do not control (a user, another service, a file) to something you do. Validate at the line.
• Allowlist means you list what is allowed and reject the rest. A denylist lists what is forbidden. Allowlists fail safe; denylists miss new tricks.
• Injection means data is treated as code or as part of a command: SQL, NoSQL operators, shell, log lines.
• SSRF (server-side request forgery) means an attacker makes your server send a request to a place the attacker cannot reach, such as an internal service or a cloud metadata address.
• Path traversal means a user-given file name like ../../secret walks out of the folder you meant.
• Prototype pollution means an attacker adds properties to Object.prototype, so every object in the program suddenly has them.
• ReDoS (regular expression denial of service) means an input that makes a badly written regex take exponential time.
• Deserialization means turning stored or received bytes or text back into objects. It is unsafe when that process can create objects or run code chosen by the attacker.
• Hash is a one-way function. A salt is random data added per password so equal passwords get different hashes. Memory-hard means the function needs a lot of RAM, which makes mass guessing on GPUs costly. Work factor is the cost setting.
• Brute force means trying many passwords for one account. Credential stuffing means trying leaked email and password pairs from other sites.
• Supply chain means all the code and tools you did not write: packages, build tools, CI actions.
• Provenance is a signed record of where and how a package was built.
• Threat model is a written answer to "what can go wrong here, and what do we do about it?".

Part 1. The map: what the OWASP Top 10 says

OWASP (a non-profit security community) publishes a list of the most common serious web risks. The 2025 edition is the current one in its repository. The items that matter for this lesson:

Use the list as a vocabulary, not a checklist. It tells you what to ask, not what is true for your app.

Part 2. Injection recap: SQL and NoSQL

You know the story: never build a query by joining strings. Here it is run, with node:sqlite and two users.

const input = "' OR '1'='1";db.prepare(`SELECT email FROM users WHERE email = '${input}'`).all();   // attackdb.prepare('SELECT email FROM users WHERE email = ?').all(input);       // fix

concatenated SQL returns 2 rows: [ 'a@x.com', 'boss@x.com' ]parameterised returns 0 rows

The ? placeholder sends the value separately from the command, so it can only ever be data. This works the same in pg, mysql2 and Prisma's tagged $queryRaw. Two limits to remember:

• You cannot parameterise names (table, column, ORDER BY field, sort direction). Allowlist them: sortable.has(col) ? col : 'id'.
• ORMs help but are not magic. $queryRawUnsafe or string-built LIKE clauses bring the problem back.

NoSQL injection is different in form. In MongoDB the query is an object, so an attacker sends JSON where you expected a string. If the login handler does User.findOne({ email: req.body.email, password: req.body.password }), the body {"email":"boss@x.com","password":{"$ne":null}} means "password not null", which is true for anyone. I tested the filter shape with sift:

Mongo-style filter from raw body matches: [ 'boss@x.com' ]

The fix is to validate the type at the edge, so an object is rejected before it reaches the database:

const Login = z.object({ email: z.email(), password: z.string().min(1).max(200) });Login.safeParse({ email: 'boss@x.com', password: { $ne: null } }).success  // false

Also keep server-side JavaScript operators in queries (like $where) off. And a password is never compared in the query anyway: you fetch the user, then verify the hash (Part 8). See Backend, Lesson 03 for validation at the edge.

Part 3. SSRF: when your server is the attacker's browser

Any feature that fetches a URL for the user is a risk: "import avatar from URL", webhooks, link previews, PDF generators, "test my endpoint". The attacker gives an address that only your server can reach: http://127.0.0.1/admin, a private network host, or a cloud metadata address such as 169.254.169.254 (OWASP lists it for AWS, GCP and Azure). On a cloud machine that address can hand out credentials, which is why SSRF is a classic way into cloud accounts. OWASP also advises moving AWS machines to IMDSv2 as an extra layer.

The attack and the first (weak) fix

I started an "internal" server on 127.0.0.1 that returns INTERNAL-SECRET-TOKEN, and a vulnerable helper fetch(url). Every one of these URLs reached it:

new URL() normalises odd forms: http://2130706433/, http://0x7f.1/ and http://127.1/ all gave the hostname 127.0.0.1, while http://[::ffff:7f00:1]/ kept the IPv6 form. So string checks like "does it start with 127." are weak. Parse first, and decide on the resolved address.

The fix, in layers

const blocked = new net.BlockList();            // 127/8, 10/8, 172.16/12, 192.168/16, 169.254/16, 100.64/10, 0/8, ::1, fc00::/7, fe80::/10function safeFetch(raw) {  const u = new URL(raw);  if (u.protocol !== 'http:' && u.protocol !== 'https:') throw new Error('scheme not allowed');  if (u.username || u.password) throw new Error('credentials in url');  const bare = u.hostname.replace(/^\[|\]$/g, '');  if (net.isIP(bare) && isBlocked(bare)) throw new Error('blocked address');   // IP literals  return http.request(u, { lookup: guardedLookup, timeout: 3000 }, onResponse); // names: checked at connect time  // onResponse: a 3xx reply is an error, we do not follow redirects}// guardedLookup: dns.lookup(host, { all: true }) and reject if ANY address is blocked;// connect to the address that was checked, so there is no second lookup.

Results of the fixed helper on the same list, plus a few more:

http://127.0.0.1:PORT/                  blocked address 127.0.0.1http://localhost:PORT/                  blocked address 127.0.0.1http://2130706433:PORT/                 blocked address 127.0.0.1http://[::ffff:127.0.0.1]:PORT/         blocked address ::ffff:7f00:1http://[::1]:PORT/                      blocked address ::1http://169.254.169.254/latest/...       blocked address 169.254.169.254file:///etc/hostname                    scheme file: not allowed302 redirect to the internal server     redirect (302) not followed   (first run; see note)

What the OWASP cheat sheet adds, which a demo cannot show:

• Allowlist when you can. If you only call known services, list their hosts and compare exactly. Do not accept "any URL".
• DNS rebinding. A name can resolve to a safe address when you check and to an internal one when you connect. The fix is the one above: validate the address you actually connect to, and apply the same rule to retries and fallbacks. I did not simulate rebinding.
• Do not follow redirects blindly. Each hop must pass the same check.
• Network layer. Put the fetching code in a network zone with no route to internal services, and use IMDSv2 on AWS. The application check alone is one layer.
• Limit the response: size, time, and content type. Never return the fetched body or error text to the user as-is.

Part 4. Path traversal

A user-given name is joined to a folder. ../ walks out of it. I made uploads/, a secret file beside it, and a symlink inside uploads/ that points to the secret:

const vulnerable = name => fs.readFileSync(path.join(uploads, name), 'utf8');function safe(name) {  if (name.includes('\0')) throw new Error('null byte');  const full = path.resolve(uploads, name);  if (!full.startsWith(uploads + path.sep)) throw new Error('outside base directory');  const real = fs.realpathSync(full);                          // follows symlinks  if (!real.startsWith(fs.realpathSync(uploads) + path.sep)) throw new Error('symlink points outside');  return fs.readFileSync(real, 'utf8');}

"report.txt"      vulnerable: public report              safe: public report"../secret.txt"   vulnerable: TOP SECRET (outside ...)   safe: BLOCKED: outside base directory"link.txt"        vulnerable: TOP SECRET (outside ...)   safe: BLOCKED: symlink points outside"a\u0000b"        vulnerable: ERR_INVALID_ARG_VALUE      safe: BLOCKED: null bytenaive startsWith(uploads) says inside? true | with sep: false

Lessons from the run:

• Resolve to an absolute path, then check it is inside the base folder. Do not search for .. in the string.
• Compare with the base plus a path separator. Without it, /data/uploads-evil/x.txt "starts with" /data/uploads. My test showed true for the naive check and false with the separator.
• A symlink can point out of the folder, so also check realpath. (Node did throw on a null byte by itself, but do not depend on that.)
• Better still: do not use user names as paths at all. Store files under an id you generate, and keep the display name in the database (Part 13).
• Express's res.sendFile and static middleware have their own root protection; the danger is code that builds paths by hand.

Part 5. Prototype pollution

In JavaScript, objects inherit from Object.prototype. If an attacker can write to it, every object gets the property. The usual route is a recursive merge of attacker JSON into a config object. Note that JSON.parse makes __proto__ a normal own key; the merge then follows it.

function merge(target, source) {            // a typical deep-merge helper  for (const key of Object.keys(source)) {    if (source[key] && typeof source[key] === 'object') { target[key] ??= {}; merge(target[key], source[key]); }    else target[key] = source[key];  }  return target;}merge({}, JSON.parse('{"theme":"dark","__proto__":{"isAdmin":true}}'));const session = { user: 'bob' };if (session.isAdmin) { /* ... */ }

JSON.parse makes __proto__ an OWN key: [ 'theme', '__proto__' ]after merge, a brand-new object has isAdmin = trueif (session.isAdmin) -> ADMIN ACCESS GRANTEDconstructor.prototype path polluted too: yes

An object that never had isAdmin now answers true. The same thing works through constructor.prototype, so blocking only __proto__ is not enough. Fixes, from the OWASP cheat sheet and my runs:

Also: check authorization with explicit data (user.role === 'admin' read from your database), never if (obj.isAdmin) on an object that might inherit.

Part 6. ReDoS

A regex with nested or overlapping repeats can try an exponential number of paths when the input almost matches. Node runs it on the main thread, so one request can freeze the server. I tried a common shape, "words separated by an optional space":

const bad = /^(\w+\s?)*$/;bad.test('a'.repeat(n) + '!');       // fails at the end, so it backtracks

words n=18:  21 mswords n=20:  14 mswords n=22:  48 mswords n=24: 134 mswords n=26: 585 ms

The time grows very fast: about 4 times more for each two added characters between n=24 and n=26 (the first rows are noisy). If that trend continued, 40 characters would take hours (my extrapolation, not a measurement). A second pattern, /^(a+)+$/, took 2334 ms at n=28 while /^a+$/ took 0 ms. An attacker's input is small, so this is a cheap attack.

Fixes:

1. Rewrite so each character can match only one way. /^\w+(?:\s\w+)*\s?$/ matched the same kind of text; on 50,000 characters plus ! it took 0.5 ms.
2. Cap the length before the regex (s.length <= 254 for an email). It is the simplest rule.
3. Do not write your own regex for emails, URLs and dates. Use a parser or a maintained schema (z.email()).
4. For regexes you must run on user data, use a linear-time engine (for example RE2 through a binding; I did not test one) or run the check in a worker you can stop. I know of no built-in timeout for RegExp in Node 22, so do not count on one.

Look for the pattern in code review: a group with + or * inside another + or *, or alternation where both sides match the same text, such as (a|a)*.

Part 7. Unsafe deserialization

Parsing data is safe. Reviving objects or functions from attacker input is not. In Node the famous cases are libraries that rebuild functions from strings. I did not install one; I wrote the same idea in six lines so you can see the mechanism:

function unsafeDeserialize(text) {                       // looks for a marker and calls eval  return JSON.parse(text, (k, v) => (typeof v === 'string' && v.startsWith('_FUNC_') ? eval('(' + v.slice(6) + ')') : v));}unsafeDeserialize('{"name":"bob","onLoad":"_FUNC_(function(){ globalThis.attackRan = true; return 1 })()"}');

unsafe: attacker code ran during parse -> true | onLoad = 1safe parse: attackRan = false | onLoad is just a string: stringschema (strict) result: rejected (unknown key onLoad)

The payload ran while parsing, before any validation could happen. My harmless payload only set a flag, but the same code could do anything the process can do. The safe version is JSON.parse (data only, no code) followed by a schema check.

Rules:

• Use JSON (or a safe format) for data from outside, and validate the shape afterwards.
• Never pass untrusted input to eval, new Function, or vm (the vm module is not a security sandbox). Do not build a "restore from a cookie or message" feature on a serializer that can create arbitrary objects.
• YAML and XML need care. Use the safe loaders of your library, and turn off external entities in XML (XXE can also cause SSRF).
• Sign what must round-trip. If a cookie or token carries data, sign it (HMAC or a JWT with a checked algorithm, see Browser, Lesson 02) and still validate after you read it.
• Limit size and depth of input at the edge. Large or deep JSON is a denial-of-service tool. (In my run, a 200,000-level nested array still parsed on Node 22.22; do not rely on the parser to stop it, use a body-size limit.)

Part 8. Password storage

Never store a password, and never store a fast hash. A fast hash like SHA-256 lets an attacker with a leaked database try guesses very quickly. I measured: on one core my machine did about 266,000 SHA-256 guesses per second in Node, and about 24 Argon2id hashes per second (at the OWASP minimum below). Real attackers use GPUs, so the gap is only a rough idea, but the direction is clear: use a slow, salted, memory-hard function.

What OWASP's Password Storage Cheat Sheet says now

It also says to tune for your server, benchmark, and consider a pepper (a secret shared by all hashes and kept outside the database, for example in a secrets vault, so a stolen database alone is not enough). Changing a pepper means every user must reset their password, so plan for it.

What I ran

const opts = { type: argon2.argon2id, memoryCost: 19456, timeCost: 2, parallelism: 1 };const h = await argon2.hash('correct horse', opts);// $argon2id$v=19$m=19456,p=1,t=2$<salt>$<hash>await argon2.verify(h, 'correct horse');                    // trueargon2.needsRehash(h, { ...opts, timeCost: 3 });            // true: raise the cost later, rehash on login

The bcrypt limit is in bytes, not characters: 19 key emoji are 19 characters but 76 bytes. If you must keep bcrypt, enforce a 72-byte maximum (the cheat sheet says so) or, if you pre-hash, follow its warning: use a keyed hash and encode the result (for example bcrypt(base64(hmac-sha384(password, pepper)))), because a plain pre-hash has known traps (null bytes, "shucking").

Good habits:

• The library generates the salt. Do not invent your own.
• Store the whole encoded string. It includes the algorithm and parameters, so you can upgrade later with needsRehash and rehash on the next successful login.
• Compare with the library's verify, not ===. For other secrets (API keys, tokens) use crypto.timingSafeEqual. It throws if the lengths differ (ERR_CRYPTO_TIMING_SAFE_EQUAL_LENGTH in my run), so hash both sides first, or compare fixed-length digests.
• Hashing is CPU and RAM heavy. Put limits on password length (for example 128 characters or less for Argon2id) so nobody can send a 10 MB "password", and rate limit logins (Part 10).
• Server-side steps for sessions and tokens are in Lesson 22.

Part 9. Security headers

Headers tell the browser how to treat your pages. In Express, helmet() sets a group of them. I printed the headers of a bare Express app and of one with helmet():

bare Express:  x-powered-by: Expresshelmet():  content-security-policy: default-src 'self'; base-uri 'self'; font-src 'self' https: data:; form-action 'self'; frame-ancestors 'self'; img-src 'self' data:; object-src 'none'; script-src 'self'; script-src-attr 'none'; style-src 'self' https: 'unsafe-inline'; upgrade-insecure-requests  cross-origin-opener-policy: same-origin  cross-origin-resource-policy: same-origin  origin-agent-cluster: ?1  referrer-policy: no-referrer  strict-transport-security: max-age=31536000; includeSubDomains  x-content-type-options: nosniff  x-dns-prefetch-control: off  x-download-options: noopen  x-frame-options: SAMEORIGIN  x-permitted-cross-domain-policies: none  x-xss-protection: 0

Helmet also removed x-powered-by. What each important one does, with OWASP's recommendation:

Part 10. Rate limiting and brute-force defence

Without limits, login is a free password-guessing machine, and expensive endpoints (search, export, password hashing, email sending) are a free way to bring you down. A rate limiter counts requests per key and answers 429 Too Many Requests after the limit.

I used express-rate-limit on a login route, keyed on IP plus the account name, counting only failed attempts, with a limit of 3 in a minute:

const loginLimiter = rateLimit({  windowMs: 60_000, limit: 3, standardHeaders: 'draft-7', legacyHeaders: false,  keyGenerator: req => `${req.ip}|${String(req.body?.email ?? '').toLowerCase()}`,  skipSuccessfulRequests: true,});app.post('/login', express.json(), loginLimiter, handler);

1 401 ratelimit: limit=3, remaining=2, reset=60  policy: 3;w=602 401 ratelimit: limit=3, remaining=1, reset=603 401 ratelimit: limit=3, remaining=0, reset=604 429 ratelimit: limit=3, remaining=0, reset=60  retry-after: 605 429 ...different account, same IP -> 401

After the third failure, the fourth request got 429 with a Retry-After header. A different account from the same IP was still allowed. Notes:

• Use more than one key. Per IP stops one machine. Per account stops many machines trying one account. Per IP only is weak against a botnet, and per account only lets an attacker lock a victim out on purpose (a denial of service), so combine them and prefer slowing (growing delays, a CAPTCHA step) over a hard permanent lock.
• Credential stuffing tries one password per account across many accounts. A per-account limit never trips. Add per-IP limits, checks against breached-password lists, and alerts on a high failure rate overall.
• Same message for "no such user" and "wrong password", and similar response time, so attackers cannot learn which accounts exist.
• Behind a proxy, req.ip is the proxy's address unless you configure Express trust proxy correctly. A wrong setting lets attackers fake their IP with X-Forwarded-For, or puts all users in one bucket.
• Memory store is per process. With many servers you need a shared store such as Redis. See Lesson 18 for counters and rate limiting in Redis.
• Limit cost, not only count. Also cap request body size, query depth, page size and upload size.
• Add MFA or passkeys for important accounts: Lesson 22.

Part 11. Secrets handling

A secret is anything that gives access: database passwords, API keys, signing keys, tokens. The OWASP secrets cheat sheet says to centralise and standardise them, limit access with least privilege, audit use, and follow a lifecycle: creation, rotation, revocation, expiration. Rotation matters because a stolen secret then works only for a short time.

Practical rules:

• Never in the repository, not even once. Removing it in the next commit does not remove it from history. If it leaked, rotate it, then clean up.
• Not in client code. Anything in a browser bundle (including NEXT_PUBLIC_ variables in Next.js) is public.
• Keep dev, staging and production secrets different, with the smallest permissions each.
• Load from the environment or a secret manager, and fail fast at start if one is missing or too weak. I ran this check and printed only the names, never the values:

const Env = z.object({  DATABASE_URL: z.string().startsWith('postgres'),  SESSION_SECRET: z.string().min(32, 'must be at least 32 characters'),});// output: [ 'SESSION_SECRET: must be at least 32 characters' ]

• Short-lived credentials (cloud roles, OIDC from CI) are better than long-lived keys in CI settings.
• Scan for leaks in CI and with a pre-commit hook (tools like gitleaks or git-secrets exist; I did not run any). Turn on your Git host's secret scanning too.
• Do not print them. Not in logs (Part 14), not in error pages, not in console.log(process.env).
• Compare tokens in constant time (timingSafeEqual, Part 8).

Part 12. Dependency and supply-chain risk

Most of your running code is other people's. Risks: a known bug in a package you use, a malicious new version, a stolen maintainer account, a typo-squatted package name, or a build script that runs when you install.

npm audit

I installed deliberately old versions (lodash@4.17.15, minimist@1.2.0) in a scratch project and ran npm audit. It reported 2 vulnerabilities (1 high, 1 critical), with links to GitHub advisories (GHSA ids): prototype pollution and command injection for lodash, and prototype pollution for minimist, with "fix available via npm audit fix". Read it as follows: audit tells you about known problems in the versions you have. It does not find new ones, and "0 vulnerabilities" is not "safe". Not every finding is reachable in your code, so triage by severity and by whether you call the vulnerable function.

Lockfiles and npm ci

A lockfile (package-lock.json) records exact versions and hashes. In CI use npm ci: it installs exactly the lockfile and stops if package.json and the lockfile disagree. I changed lodash to 4.17.21 in package.json without updating the lock, and npm ci stopped with:

npm error `npm ci` can only install packages when your package.json and package-lock.json ... are in sync.npm error Invalid: lock file's lodash@4.17.15 does not satisfy lodash@4.17.21

Commit the lockfile and review its diff in pull requests; an unexpected new package or a changed registry URL is a warning.

Install scripts

A package can run a script when installed (postinstall). I made a harmless local package whose postinstall writes a file in my home folder:

npm i ../evil --ignore-scripts   -> file not creatednpm i ../evil                    -> "a package script ran on install"

OWASP advises installing with --ignore-scripts, or setting ignore-scripts=true in .npmrc, and allowing scripts only for the few packages that need them (native modules). Note this protects the install step; code can still do harm when you run it.

Provenance, signatures and publishing

• Provenance (a signed statement of which source and CI built a package) is created automatically when a maintainer publishes with trusted publishing, which uses OIDC from the CI provider instead of a long-lived npm token. OWASP recommends it. As a consumer, npm audit signatures checks registry signatures and provenance attestations. It failed in my sandbox (403 while fetching the signing keys), so I have not seen its output.
• Maintainers: turn on 2FA, use granular, short-lived tokens or trusted publishing, and do not publish secrets inside the package.
• Consumers: be careful with new, rarely used packages. Check the name for typos (typosquatting), and be careful with names suggested by a code assistant that may not exist (slopsquatting: an attacker registers a name that an AI tool made up). Avoid running copied install commands you did not read.
• Pin and update on purpose. Use a bot (Dependabot or Renovate) so updates arrive as reviewable pull requests, and read the release notes of big jumps. Some teams add a short waiting period before adopting a brand-new release.
• Dependency confusion: if you use private package names, make sure the public registry cannot supply a package with the same name (use scoped names and registry settings).
• Keep an inventory (an SBOM) if your customers ask for it. The frontend side of this (Subresource Integrity, third-party scripts) is in Browser, Lesson 07.

Part 13. File upload safety

An upload takes attacker bytes and puts them on your disk, often to be served back to other users. OWASP's file upload list is: allow only needed extensions, check the real content (not the Content-Type header, which can be faked), generate your own file name, set size and name-length limits, require login, store files outside the web root or on another server, scan if you can, and protect the route from CSRF.

I wrote the checks as one function and ran it on eight inputs:

const TYPES = { png: { magic: [0x89,0x50,0x4e,0x47,0x0d,0x0a,0x1a,0x0a] }, jpg: { magic: [0xff,0xd8,0xff] } };function checkUpload({ originalName, bytes }) {  if (bytes.length === 0 || bytes.length > MAX) return { ok: false, why: 'size' };  const ext = path.extname(originalName).slice(1).toLowerCase();  const rule = TYPES[ext];                                         // allowlist of extensions  if (!rule) return { ok: false, why: `extension .${ext} not allowed` };  if (!startsWith(bytes, rule.magic)) return { ok: false, why: 'content does not match extension' };  return { ok: true, storedAs: `${randomUUID()}.${ext}` };         // our own name}

Also remember: a file-signature check proves only the first bytes. Re-encoding images (decode, then save again, stripping metadata) is stronger, and OWASP says ZIP files are not recommended, because they can hold anything. SVG can carry script, so allow it only if you sanitise it or serve it as a download. Serve user files from a separate domain with Content-Disposition: attachment where possible, and X-Content-Type-Options: nosniff. For large files, uploading directly to object storage with a short-lived signed URL keeps the bytes off your server (Lesson 23).

Part 14. Logging without leaking secrets

Logs are how you find an attack, and also a place where secrets end up. OWASP says tokens, session ids, passwords, database connection strings, encryption keys, card data and sensitive personal data should be removed, masked, hashed or encrypted before logging. It also says to sanitise event data against log injection (CR, LF and delimiter characters).

Log injection, run:

const user = 'bob\n2026-10-11 INFO login ok user=admin';console.log(`2026-10-11 WARN login failed user=${user}`);

2026-10-11 WARN login failed user=bob2026-10-11 INFO login ok user=admin          <- a forged line

A structured logger (JSON) escapes the newline. With pino and a redact list:

const log = pino({ redact: { paths: ['req.headers.authorization', 'req.headers.cookie', '*.password', 'body.token'], censor: '[Redacted]' } });log.warn({ user, req: { headers: { authorization: 'Bearer abc.def.ghi', cookie: 'sid=123' } }, body: { token: 't0k3n', email: 'bob@x.com' }, input: { password: 'hunter2' } }, 'login failed');

{"level":40,...,"user":"bob\n2026-10-11 INFO login ok user=admin","req":{"headers":{"authorization":"[Redacted]","cookie":"[Redacted]"}},"body":{"token":"[Redacted]","email":"bob@x.com"},"input":{"password":"[Redacted]"},"msg":"login failed"}

The newline is now inside a JSON string (\n), and the secrets are replaced. But redaction only works on paths you list. My next line, log.warn({}, 'password was hunter2'), printed the password in the message text, because it is not a field. So:

• Log fields, not interpolated strings that may hold secrets.
• Keep an allowlist of fields to log for requests; do not log whole request or response bodies, headers or process.env.
• Log the event (login failed, user id, request id, source IP), not the secret. For a session id, log a hash.
• Error pages for users: a generic message and a trace id. Details only in logs. See Backend, Lesson 05 for structured logging and request ids.
• Treat log storage as sensitive: restrict access, set retention, and make sure logs cannot be changed by the app that writes them.
• Do alert on important events (many failed logins, blocked SSRF attempts, 429 spikes). Logging with no alerting is how breaches go unseen for months (the OWASP item A09).

Part 15. A short threat-modelling routine

Threat modelling is thinking about attacks before writing code. The Threat Modeling Manifesto, quoted in the OWASP cheat sheet, uses four questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

A routine that fits a 30-minute design review:

STRIDE is the one OWASP recommends to start with for a technical design, and it says to review the model with the whole team, not only security staff. Keep the result in the repository as a short document next to the code.

Common mistakes

• Trusting a request field because the frontend "already validated it".
• Checking a URL string with startsWith or a regex instead of checking the resolved IP address, and forgetting that IP literals skip DNS.
• Following redirects in server-side fetches.
• Blocking __proto__ only, or checking a path with includes('..').
• Using startsWith(base) without a trailing separator.
• A regex with a group repeated inside a group repeated, run on user text with no length limit.
• Using eval, new Function or vm on data from outside.
• Hashing passwords with SHA-256, using bcrypt with passwords longer than 72 bytes, or rolling your own salt.
• Setting helmet() defaults and never testing that the CSP does not break the app, or setting HSTS preload without reading the rules.
• A login limiter keyed only on IP (botnets) or only on account (lock-out attacks).
• A secret in a commit "just for a minute", or a secret in a NEXT_PUBLIC_ variable.
• Treating npm audit as a verdict, or running npm install instead of npm ci in CI.
• Trusting the upload's Content-Type and file name.
• Logging whole request bodies, or building log lines from user text.

Interview questions

Key takeaways

• Treat every outside value as hostile at the trust boundary: validate with strict schemas and allowlists.
• SSRF: parse the URL, allow http(s) only, check resolved and literal IPs, connect to the checked address, refuse redirects, limit size and time, isolate the network.
• Paths: resolve, then check inside the base with a trailing separator, and check symlinks. Prefer generated ids.
• Prototype pollution: strict schemas, skip dangerous keys, Map or Object.create(null), update libraries.
• ReDoS: no repeated groups inside repeated groups, cap input length, prefer maintained validators.
• Never eval outside data. Parse data, then validate.
• Passwords: Argon2id (for example m=19456, t=2, p=1 as a minimum), scrypt or bcrypt (72-byte limit) as fallbacks; store the encoded string and rehash when you raise the cost.
• Headers and rate limits are layers, not fixes. Use several keys for login limits and avoid easy lock-out attacks.
• Secrets stay out of the repo and the browser. Rotate after exposure. Fail fast on bad config.
• Use npm ci, a committed lockfile, ignore-scripts with an allowlist, audit as one input, and provenance where possible.
• Uploads: allowlist, check bytes, generate the name, limit size, serve safely.
• Log fields, redact by path, and alert. Threat model before you build, with STRIDE.

What's next

Practise by attacking your own small project: write the vulnerable version of each demo, break it, then fix it and keep the test. For the browser half of this topic read Browser, Lesson 07 and Browser, Lesson 03, and for sign-in design read Full-Stack Q&A, Lesson 22.