01 Sample report

This is what €299 buys.

Below is a sample of the audit report format, populated with the issues we most commonly find in Lovable, Bolt and v0 apps, so you can judge the depth before you pay. It is a sample of the format, not a real client's report. Client reports are confidential.

Report structure: executive summary in plain language → severity-ranked findings (what, why it matters, how to fix, effort) → a fixed-price quote to fix the criticals → a “fine as-is” list of what we checked and did not flag. Five findings shown here; real reports typically run 8–15.

CRITICAL Auth & access control Finding 1 of 5 · est. fix 4–6 h

Row-level security disabled on user tables

The Supabase tables holding user profiles and orders have RLS off. Any visitor with the public anon key, which ships in your frontend bundle by design, can read and modify every row via the auto-generated REST API.

Fix: Enable RLS on all tables; add per-user policies (auth.uid() = user_id); verify with an anonymous-role test suite.

CRITICAL Secrets Finding 2 of 5 · est. fix 2–3 h

Service-role key committed to git history

The Supabase service-role key (bypasses RLS entirely) appears in commit history from an early .env commit. Deleting the file later does not remove it from history.

Fix: Rotate the key immediately; purge history (git filter-repo) or rotate + accept history; move secrets to platform env vars; add secret scanning to CI.

HIGH Payments Finding 3 of 5 · est. fix 4–8 h

Checkout success screen without server-side verification

The app shows "Payment successful" based on the client-side redirect alone. There is no webhook verifying the Stripe event, so a user can reach the paid state without a completed charge, and real failed payments look identical to successes.

Fix: Implement the checkout.session.completed webhook with signature verification; gate paid features on the verified server-side state.

HIGH Error handling Finding 4 of 5 · est. fix 2–4 h

API routes return stack traces to the client

Unhandled exceptions in API routes return full stack traces (file paths, query fragments) to the browser: useful reconnaissance for an attacker, confusing for users.

Fix: Add a global error boundary on API routes: log the full error server-side, return a generic message with a correlation ID.

MEDIUM Monitoring Finding 5 of 5 · est. fix 2–3 h

No error tracking or uptime monitoring

There is no way to know the app is broken until a customer emails. No Sentry/uptime check, no alerting, and "production" shares a database with preview deployments.

Fix: Add Sentry (or similar) + a free uptime monitor; separate the production database from previews; alert to email.

Then the report ends with a number

Every report closes with a fixed-price quote to fix the criticals (most apps fit the €990 critical fix sprint, and the €299 audit fee is credited) and an honest list of what we checked and found fine, so you know what you're not paying to fix.