Skip to content
Vibe2Prod
Menu

Sample report

I broke an app on purpose, then audited it.

No customer’s report to redact, so I made my own subject: an invoicing app built the way these tools build them, with the defects they typically produce, planted deliberately. Then the audit ran over it, exactly as it would run over yours, and every finding is published. Nothing is blurred out, because there is nobody to protect.

It runs long, because thirty-three findings need the room. Yours will be as long as your app makes it: a page where a page is warranted, and nothing padded to look thorough. This one was built to be broken, so it sits at the heavy end.

Two documents

One you can check, one that reads like yours.

The specimen is real code with the defects planted in it, so a stranger can verify a finding without taking my word for anything. The composite has no real subject at all, which is what lets it read like a client engagement rather than a teaching exercise.

33 findings · 7 critical

The InvoicePilot specimen

An invoicing app I built and broke, then audited. Every finding names a file and a line you can open yourself.

Read the specimen

13 findings · 3 critical

The Loopin composite

A client portal that never existed, written at the length a real report runs, about the app a buyer recognises as theirs.

Read the composite

What it demonstrates

The five flaws, and how findings read.

What to judge before paying: whether the checks cover what matters — hardcoded keys, RLS disabled, missing input validation, broken auth logic, console and data leakage — and whether the report reads like something you can act on. Judge the second part now:

SEVERITY COUNT · INVOICEPILOT DEMO AUDIT33 findings
Critical
7
High
8
Medium
14
Low
4
Thirty-three findings on an app built to be broken. Yours will produce whatever it produces; the number is a description, not a grade.
Criticalfinding 1 of 33 · demo audit

The database master key is compiled into the app every visitor downloads.

What I saw

  • src/lib/supabase.ts:5 — the Supabase service-role key, read into browser code
  • dist/assets/index-*.js:95 — confirmed in the built bundle served to every visitor
  • "role":"service_role" — decoded from the token itself, valid until 2034

What it costs you if it triggers

Anyone who opens the site and presses F12 gets unrestricted read and write access to the whole database: every customer, every invoice, every account. No login, no exploit, no skill. And because the key is already published, you cannot know whether it has been taken — it has to be treated as compromised.

How to fix it

Rotate the key first; the published one is burned, and code changes are worthless while it still works. Then delete the browser-side admin client and move the four privileged operations behind server endpoints that check who is calling.

Paste-ready prompt

In this Vite + React + Supabase project, the Supabase service-role key is being exposed to the browser. Fix it as follows, and do not preserve any browser-side path to the service role. 1. In src/lib/supabase.ts, delete the supabaseServiceKey constant and the exported supabaseAdmin client…

After the AI applies it, check: rebuild, search the new bundle for the old key — it must be gone, and the app must still load on the anon key alone.

From the InvoicePilot demo audit — an app I broke on purpose so a full report could be shown in public. The complete finding runs a page; 28 more follow it.

Report anatomy

Every report follows this shape.

  1. Summary and severity count

    How many findings, at which severities, and which of the five flaws appeared — in the shape of “N findings: X critical, Y high”. A count, never a score.

  2. Findings, one by one

    Each finding carries the evidence it was found from, the business consequence if it triggers, and the fix — ranked Critical / High / Medium / Low.

  3. Paste-ready fix prompts

    For findings fixable with your own AI tooling: the prompt to paste, plus what to check after your AI applies it.

  4. Supply-chain picture

    The packages the app pulls in: versions frozen at generation time, and any whose provenance the repository cannot establish. Published advisories are checked by hand and attributed to a person.

  5. What I could not see

    The audit’s limits, stated explicitly, so the unmeasured risks are on the table too.

  6. A 30-day priority order

    What to fix first, what can wait — the report as a plan.

What you will not find in it: a readiness score, a green light, or a verdict. The line between findings and verdicts is drawn on the published standard.

Next step

Want this written about your app?

A report within 48 hours of the scheduled start, and a fit check that says no when the audit is not the right thing.

€350 + VAT · €430.50 including VAT.