This is what you get.

What's wrong

The invoice endpoint loads an invoice by its ID and returns it without checking that it belongs to the caller's organisation. Invoice IDs are sequential, so they are easy to enumerate.

Evidence

// src/api/invoices/[id].ts:14
export async function getInvoice(req: Request, res: Response) {
  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id },          // <- no organisation filter
  });
  if (!invoice) return res.status(404).end();
  return res.json(invoice);
}

On staging, a user in test organisation B retrieved invoice 10412, which belongs to organisation A, with a single request. The same pattern appears in 4 of the 23 tenant-scoped endpoints (listed in the appendix).

Impact

Any paying customer could download every other customer's invoices: names, addresses, amounts and bank details. That is a reportable personal-data breach under GDPR.

Fix

const invoice = await db.invoice.findFirst({
  where: { id: req.params.id, orgId: req.user.orgId },
});

Then move tenant scoping into one shared data-access helper so a new endpoint can't forget it, and add a test that calls each endpoint as the wrong tenant. Effort: half a day for the four endpoints, one day for the helper and tests.

Status

Fixed in commit 7c1e0b3 on Day 4. Verified on staging on Day 5: all 23 endpoints return 404 for another organisation's records.

What's wrong

The payment provider signs every webhook. The handler never checks that signature, so it trusts any request sent to the URL.

Evidence

// src/webhooks/payments.ts:9
app.post('/webhooks/payments', express.json(), async (req, res) => {
  const event = req.body;                  // <- signature header never checked
  if (event.type === 'invoice.paid') {
    await markPaid(event.data.object.metadata.invoiceId);
  }
  res.sendStatus(200);
});

Impact

Anyone who knows the webhook URL, which appears in the frontend bundle's error-reporting config, can mark any invoice as paid and unlock paid features without paying. The preconditions are knowing the URL and an invoice ID, which is why this is High rather than Critical.

Fix

Verify the signature using the raw request body and the signing secret, using the provider's SDK. Reject events older than five minutes, and store processed event IDs so a replayed event is ignored. Effort: about two hours.

Status

Open. Agreed fix date 18 October 2026; included in the re-test.

What's wrong

A password reset link stays valid forever and keeps working after it has been used. The token is stored in plain text, and changing the password doesn't end existing sessions.

Evidence

// src/auth/reset.ts:22
export async function requestReset(email: string) {
  const user = await db.user.findUnique({ where: { email } });
  if (!user) return;
  const token = crypto.randomBytes(32).toString('hex');
  await db.user.update({
    where: { id: user.id },
    data: { resetToken: token },           // <- stored in plain text, no expiry
  });
  await mailer.sendPasswordReset(user.email, token);
}

// src/auth/reset.ts:41
export async function resetPassword(token: string, password: string) {
  const user = await db.user.findFirst({ where: { resetToken: token } });
  if (!user) throw new BadRequestError();
  await db.user.update({
    where: { id: user.id },
    data: { passwordHash: await hash(password) },  // <- token not cleared, sessions kept
  });
}

On staging, a reset link requested on Day 1 still worked on Day 4. The same link worked a second time after the password had already been changed, and the session from before the reset stayed logged in throughout.

Impact

Anyone who ever gets hold of an old reset email can take over that account at any time: a forwarded or shared mailbox, a former employee, or a leak of the email provider's logs. The real user changing their password doesn't lock them out, and nothing alerts the user. The precondition is access to a past reset email, which is why this is High rather than Critical. Because the tokens are stored in plain text, a database leak would expose every pending reset as well.

Fix

Store only a hash of the token, with an expiry of 30 to 60 minutes. Clear it the moment it's used, and invalidate any other outstanding tokens for that user. End all existing sessions when the password changes, and email the user to say it was changed. Add tests for an expired token, a reused token and session invalidation. Effort: half a day including tests.

Status

Open. Agreed fix date 18 October 2026; included in the re-test.