The whole audit on one page: what I checked, how long it took, and every problem ranked by how bad it is. Each one says what it means for Northwind, and a button shows it happening for real.
A week before launch I spent five days on Northwind's new client cabinet — logging in, opening invoices, paying, and the help bot. Here is everything I found, worst first, each with a button that shows it happening for real.
8 of 12 already have a whole chapter in Parts 1–4. The rest are new to this cabinet.
The automatic tools found 0 of these 12. They flag out-of-date libraries and stray passwords, not bugs in how money and files move. All of these came from reading the code.
Worst first. Each one: what's wrong, what it means for Northwind, a button that shows it happening, and the fix in one line with a link to the chapter that explains it.
The cabinet's code is open — read it on GitHub →The master key to the whole database is sitting in the web page, where any visitor can copy it.
With that key, anyone reads and changes every client's invoices and files directly, not just their own. The login in front of it stops nothing.
Keep the full-rights key on the server; give the browser a key scoped to the logged-in client, or no key at all.
4.1 Someone Else's Files →To see an invoice the cabinet only checks that you're logged in. Change one number in the address and you're looking at another client's invoice.
Logged in as Brightlane, change the number and another client's invoice opens: amount, plan, payment status. Nothing was hacked.
Check the invoice belongs to the logged-in client, and let the database refuse the rest even if a page forgets.
4.1 Someone Else's Files →When the payment company says an invoice is paid, the cabinet doesn't check the message is really from them. A faked message works just as well.
A €5,800 invoice flips to paid with no money behind it. The studio ships the work, then finds the money never arrived.
Verify the provider's signature over the raw body before acting, and ignore anything that fails.
2.3 Webhooks →If you tap Pay twice, or your phone retries, you're charged twice for the same invoice.
The €5,800 Studio retainer comes out of a client's account twice. They notice before the studio does.
Carry one idempotency key per payment all the way to a unique constraint in the database.
2.2 Idempotency →The help bot reads every client's files to answer anyone. It just hides where the answer came from.
A client asks about their own project and the answer quotes Tidepool's confidential file. Tidepool signed a confidentiality clause.
Search only the files that client may open, so the bot never reads the rest.
4.2 The Bot Knows Too Much →Money is kept as the kind of number that can't hold exact cents. Split a bill in two and a cent goes missing.
Split invoices and partial payments stop adding up. By month end the books and the bank disagree, and nobody can say why.
Store money as whole cents in integers; split with a method that assigns the leftover cent on purpose.
2.6 Money Math →Anything a client puts in a brief is sent to the AI as-is, even personal details they shouldn't have shared.
Halden's brief has patient records in it. They leave the building for a third-party model with the rest of the text.
Swap personal data for placeholders before sending, and put it back only for the person reading the answer.
4.4 What Leaves for the AI →A link to a file works forever, for anyone who has it, long after the project ends.
The freelancer who rebuilt the cabinet still has links to a finished project's files. They open fine today.
Sign links, expire them in minutes, bind them to one person, and kill them when access is revoked.
4.6 The Link That Never Dies →Nothing stops someone trying thousands of passwords, or asking the bot so many questions it runs up a bill.
One client account is one guessed password away from the invoices behind it, and the AI bill has no ceiling.
Count attempts per account and per address, slow them down after a few, and cap the bot's spend.
The cabinet is backed up every night, but nobody has ever checked that a backup can actually be put back.
The one morning the database is lost, the studio finds out whether the backups work. A backup you can't restore is a file, not a backup.
Restore a backup into a scratch database on a schedule and check row counts; a backup is only real once it's been put back.
The cabinet writes its passwords and keys into its logs, where more people can see them than should.
The secrets you'd rotate after a breach are already sitting in the log history, waiting to be read.
Keep secrets out of logs; redact known key shapes before anything is written.
There's only the live site. New versions go straight onto it from someone's laptop, with nowhere to test first.
Every change is tried for the first time on real clients. A bad release is live until someone's laptop fixes it.
Add a staging copy, deploy from a pipeline, and keep the last good release to roll back to.
That's what the call is for. Tell me how your product works, and I'll tell you what applies to you and what I'd check first.