Vulnerable: src/app.js builds the page with a template string, ${user.bio}, so the bio is parsed as HTML. The payload's <img onerror> runs in the viewer's browser: the banner says script executed. In a real app that script runs with the site's origin and can call the API as the viewer.

Fixed: the page uses an html tagged template that HTML-escapes every interpolated value (& < > " '), so the payload shows up as visible text. The fix is output encoding; the 500-character limit on the bio is only hygiene. Switch the target to fixed at the top and repeat.

Vulnerable: one request, two log lines. The second line is attacker text but looks exactly like a real INFO login ok for admin entry (same timestamp format, same words). Anyone who greps the log or builds an alert from it is misled. CWE-117.

Fixed: logger.js writes one JSON object per event; JSON.stringify turns the newline into the two characters \n, and the username is a quoted field that cannot become a log line or a different field. The username is also cut to 64 characters.

Vulnerable: every id from 1 to 4 answers 200 with email, phone and the HR note. The handler proves who you are (authentication) and never asks whether you may see this record (authorization). Nothing in the code says "this is wrong": whether Alice may read Bob's record is a business rule, which is why a scanner cannot decide it and a reviewer must.

Fixed: canAccessUser(req.user, id) allows the owner or an admin and denies everything else (403 here; some teams return 404 so ids are not confirmed to exist). The public profile page stays readable by any signed-in user because it only shows public fields.

Vulnerable: md5(password) is fast and has no salt. Alice and Carol have the same password and the same stored value; one precomputed table cracks every account that uses a listed password in a single pass (the benchmark finds sunshine1 and letmein instantly; the admin's longer password is not in the list). The comparison === on hashes is also not constant-time, but in this design the attacker does not control the stored hash, so treat that as a lint-level finding next to the real problem.

Fixed: scrypt with a random 16-byte salt per password and the OWASP minimum cost (N=2¹⁷, r=8, p=1), compared with crypto.timingSafeEqual. Equal passwords store different values, and each guess costs a measurable fraction of a second of CPU and 128 MiB of memory. Weak passwords still fall to a determined attacker; the goal is to make every guess expensive, and to make sure a login attempt on an unknown user costs the same (the fixed code hashes a dummy value).

Vulnerable: the secret is the string changeme in source code, and it is in the word list. Anyone who reads the repository, or guesses, can mint a token for any user and role; the server trusts the claims because the signature checks out. Step 4 returns 401 on both versions: the installed jsonwebtoken 9 only accepts HMAC algorithms when you pass it a string secret, so the missing algorithms option is not exploitable here. Pin it anyway (RFC 8725 section 3.1) so a future key or library change cannot widen what is accepted.

Fixed: the secret comes from JWT_SECRET (the app refuses to start without 32+ characters), verification uses { algorithms: ['HS256'] }, and tokens last 15 minutes. The forged token gets a 401.

Happy path: 6 of 6 pass on both versions. Hostile suite: on the vulnerable app 6 of the 7 tests fail (XSS, log injection, IDOR, both password checks and the JWT forgery); the seventh, alg: none, passes on both versions because the library already refuses it. On the fixed app all 7 pass. The tests are the proof that the fix holds, and they belong in CI so the bug cannot come back.