Six ways to break a web app, and how to fix every one.

What is this, in one breath

Imagine a small web app that stores invoices. It works fine. But hidden inside it are six classic security bugs — the same kinds that show up in real companies every week. SecureFix is a guided tour of those six bugs.

The trick is that it shows both sides of the desk. First the attacker's view: the exact trick that breaks the app. Then the engineer's view: the fix, and an automatic guard that fails the build if anyone reintroduces the bug. Learning one side without the other is how bugs keep coming back. This does both.

The loop, repeated six times

Every bug in this project goes through the same four steps. Once you see the loop once, the other five are variations on it.

find it → fix it → teach a robot to catch it → block it forever

The app you'll be breaking

It's deliberately boring: an invoice service with two users and three invoices. Boring is the point — it keeps your attention on the bug, not on a maze of features.

Keep this cast in mind: whenever alice manages to read invoice #3, she's read something that belongs to bob. That's the whole shape of several bugs below.

Break it, then fix it

Each tab is one bug. You'll get a plain-English analogy, the trick that breaks it, the fix side by side with the broken code, and the rule that catches it next time.

db.prepare(
  `SELECT id, description, amount
   FROM invoices
   WHERE description LIKE '%${q}%'`
).all();  // q is glued in raw

db.prepare(
  'SELECT id, description, amount
   FROM invoices
   WHERE description LIKE ?'
).all(`%${q}%`); // q is bound, not parsed

db.prepare(
  'SELECT ... FROM invoices
   WHERE id = ?'
).get(id); // which user? nobody asked

db.prepare(
  'SELECT ... FROM invoices
   WHERE id = ? AND owner_id = ?'
).get(id, ownerId); // must be yours

const url = req.body.url;
const r = await fetch(url);
// fetch anything, anywhere

const safe = assertPublicHost(url);
const r = await fetch(safe);
// blocks internal / metadata IPs

res.send(
  `<div>${note}</div>`
); // note becomes live HTML

res.send(
  `<div>${escapeHtml(note)}</div>`
); // < and > become harmless text

jwt.decode(token)
// reads claims, checks nothing

jwt.verify(token, SECRET,
  { algorithms: ['HS256'] })
// checks the seal, pins the method

target[key] = source[key];
// key can be "__proto__"

if (FORBIDDEN.has(key)) continue;
target[key] = value;
// skip __proto__ / constructor

How the code-scanner "thinks"

The tool doing the catching is Semgrep. Think of it as a spell-checker, but for dangerous code shapes instead of typos. You write a rule once, and it reads every file looking for that shape. Two flavours show up in this project.

Pattern rules — match a shape

The simplest rules describe a shape of code, like "a query built with ${...} glued inside it." Fast and blunt. Good for the obvious cases, but they can't tell whether the data is actually dangerous — only what the code looks like.

Taint rules — follow the dye

The smarter rules (SSRF, XSS) trace a drop of dye. They mark anything from the request as "tainted", then watch to see if it reaches a dangerous place — a fetch(), an HTML response — without passing through a cleaning step first. If it does, that's the bug. This is why the fix works by routing the value through a named cleaner: the tracker sees it get washed and stops worrying.

The gate: red before, green after

The project keeps two copies of the code. One has all six bugs; one has all six fixes. The exact same automated pipeline runs on both — and that's the proof the loop works.

On the buggy copy the scanner finds seven problems and fails the build (red). On the fixed copy it finds nothing and the build passes (green). Wire that scanner into CI and nobody can merge one of these bugs back in without the build going red first. That's the "prevent" step — the bug is caught by a machine, not by hoping a human notices.

Why seven findings for six bugs? Prototype pollution trips two separate rules.