(01) ServicesSample audit

What an audit looks like.A full sample report.

This is the report you'd get for your app: a summary in plain words, a scorecard, every finding with the code that proves it, and a plan with hours.

Sample, not a client

This is a sample. The app, its founder and its numbers are made up, but every finding is a real problem I see in apps built with AI tools.

Skip to findings

Report cover

App: Mealbox, a weekly meal-kit subscription (fictional)
Built with: Lovable: React and Vite, Supabase (database, sign-in, edge functions), Stripe
Scope: The code repository, the Supabase project and the live site, signed in as a test customer
Date: October 2026
Auditor: Hansraj Saini, HS
Time spent: 4 days

(02) Summary

Is it safe to launch?The short answer first.

Verdict

Not safe to launch yet.

Fix the three critical findings before you take another payment. They're about a day and a half of work.

Mealbox works well as a product: sign-up, picking meals and paying all do what a customer expects, and card details never touch your servers because checkout runs on Stripe's own page.

The problems are behind the screens. Three of your database tables are open to anyone who looks, a master key to the database ships inside the website, and the code that marks an order as paid will believe a fake message.

None of this needs a rewrite. Every fix below keeps the code you have. I'd do security in week one, code health in week two and speed and Google in week three.

Findings by severity

Critical
3
Fix before your next user signs up.
High
3
Fix this week.
Medium
3
Fix before you grow.
Low
1
Fix when you're in there.

Fix first

Customer addresses and orders are readable by anyone (MB-01)
The database master key ships inside the website (MB-02)
Anyone can fake a 'payment received' message (MB-03)

Already good

Sign-in uses Supabase Auth properly, with no home-made passwords.
Card payments run on Stripe Checkout, so card numbers never reach your code.
The code is in Git with a readable history, which makes every fix below easier.

(03) Scorecard

Eight areas, checked.Where the app stands on each.

Database access rules
Fail
Rules off on three tables.
MB-01
Secret keys in the browser
Fail
Master key in the website.
MB-02
Checks on the server
Fail
Server trusts the browser twice.
MB-04 MB-05
Payment webhooks
Fail
Messages aren't verified.
MB-03
Outdated packages
Needs work
One known hole, twelve behind.
MB-07
Errors, logs and limits
Fail
No limits, no alerts.
MB-06 MB-08
Pages Google can render
Needs work
Empty pages before JavaScript.
MB-09
Speed on a real phone
Needs work
About 7 seconds to show content.
MB-10

(04) Findings

10 findings,each with proof and a fix.

MB-01
Critical
Effort 3 h
Customer addresses and orders are readable by anyone
WhereSupabase: public.profiles, public.orders, public.addresses
What's wrong
Supabase protects each table with rules that say who can see which rows. On three tables those rules are switched off, so the database answers any request that carries the public key, and the public key is in your website for anyone to copy.
Why it matters
Anyone can download every customer's name, phone number, home address and order history in one request. That's a data breach you would likely have to report in the UK and EU, and the kind of thing that ends up on social media.
Evidence
```
-- Supabase SQL editor
select tablename, rowsecurity
from pg_tables where schemaname = 'public';

 tablename   | rowsecurity
-------------+------------
 profiles    | false
 orders      | false
 addresses   | false
 meal_plans  | true

-- From any laptop, with the key from the site's JavaScript:
-- curl "https://<project>.supabase.co/rest/v1/addresses?select=*" \
--   -H "apikey: <anon key>"
-- → 1,240 rows, every customer's address
```
The fix
Turn the rules on for all three tables and add one rule per table: a customer can see and change only their own rows. Then test as two different customers to prove neither can see the other.
For your developer
Enable row level security on each table, then a policy per table: for all using (auth.uid() = user_id) with check (auth.uid() = user_id). profiles keys on id, not user_id. Check the admin dashboard still works: it should go through an edge function (see MB-02), not the anon client.
MB-02
Critical
Effort 3 h
The database master key ships inside the website
Where.envsrc/lib/adminClient.tsdist/assets/index-*.js
What's wrong
Supabase gives you two keys: a public one for the browser and a secret one that skips every rule. The secret one is stored in a setting that starts with VITE_, and Vite copies every VITE_ setting into the JavaScript that visitors download.
Why it matters
With this key, anyone can read, change or delete anything in your database, including the rules from MB-01, so fixing MB-01 alone isn't enough. The .env file is also in the repository, so anyone who has ever had access to the code has the key.
Evidence
```
# .env (committed to the repo)
VITE_SUPABASE_URL=https://<project>.supabase.co
VITE_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...
VITE_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIs...

// src/lib/adminClient.ts
export const admin = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY,
);

$ grep -c "service_role" dist/assets/index-*.js
1
```
The fix
Replace the secret key in Supabase so the leaked one stops working, move the few admin actions that need it to a server function, and take the .env file out of the repository.
For your developer
Rotate the service_role key (or move to the new secret API keys) in the Supabase dashboard. Move the three admin queries in adminClient.ts into an edge function that checks the caller is an admin, reading the key from Deno.env. Add .env to .gitignore and purge it from history with git filter-repo; treat the old key as public regardless.
MB-03
Critical
Effort 2 h
Anyone can fake a 'payment received' message
Wheresupabase/functions/stripe-webhook/index.ts
What's wrong
When someone pays, Stripe sends your server a message saying so, and your server marks the order as paid. Stripe signs each message so you can tell it's genuine, but your server never checks the signature. It believes any message that looks right.
Why it matters
Someone who finds the address (it's guessable) can send a fake 'paid' message and get a box of food every week without paying. You'd only notice when the Stripe payouts don't match the orders.
Evidence
```
Deno.serve(async (req) => {
  const event = await req.json();   // no signature check
  if (event.type === "checkout.session.completed") {
    await markOrderPaid(event.data.object.metadata.order_id);
  }
  return new Response("ok");
});
```
The fix
Check Stripe's signature on every message and reject any that fail. Then check the order against Stripe itself before marking it paid.
For your developer
Read the raw body with req.text(), then stripe.webhooks.constructEventAsync(body, req.headers.get("stripe-signature"), STRIPE_WEBHOOK_SECRET, undefined, Stripe.createSubtleCryptoProvider()). Return 400 on failure. Make markOrderPaid idempotent on the event id, since Stripe can deliver the same event twice.
MB-04
High
Effort 2 h
The browser decides how much a plan costs
Wheresrc/pages/Checkout.tsxsupabase/functions/create-checkout/index.ts
What's wrong
The checkout page tells the server the price, and the server passes that number straight to Stripe. Anyone can change the number in their browser before it's sent.
Why it matters
A customer can subscribe to the family plan for $1 a week. Stripe will happily charge $1, and the order looks paid, so nothing flags it.
Evidence
```
// src/pages/Checkout.tsx
await supabase.functions.invoke("create-checkout", {
  body: { planId: plan.id, amount: plan.price * 100 },
});

// supabase/functions/create-checkout/index.ts
line_items: [{
  price_data: {
    currency: "usd",
    unit_amount: body.amount,        // from the browser
    recurring: { interval: "week" },
    product_data: { name: "Mealbox plan" },
  },
  quantity: 1,
}],
```
The fix
Set up each plan as a fixed price in Stripe and have the server look it up from the plan the customer picked. The browser sends which plan, never how much.
For your developer
Create one Stripe Price per plan and store its id in meal_plans.stripe_price_id. In create-checkout, accept only planId, look up the price id server-side and pass line_items: [{ price, quantity: 1 }]. Ignore any amount in the body.
MB-05
High
Effort 3 h
One customer can change another customer's subscription
Wheresupabase/functions/update-subscription/index.ts
What's wrong
To pause or change a plan, the app sends the server a customer ID along with the change. The server trusts that ID instead of checking who's actually signed in, and it uses the master key, so no database rule stops it.
Why it matters
A signed-in customer can pause, cancel or upgrade someone else's subscription by editing one value in the request. Customer IDs appear in other responses, so they're easy to find.
Evidence
```
const { user_id, plan_id, pause_until } = await req.json();
const supabase = createClient(URL, SERVICE_ROLE_KEY);  // skips every rule

await supabase
  .from("subscriptions")
  .update({ plan_id, pause_until })
  .eq("user_id", user_id);   // whoever the request says
```
The fix
Work out who's signed in from their login, on the server, and only ever change that person's subscription. Use the normal key so the database rules from MB-01 apply too.
For your developer
Create the client with the anon key and the caller's Authorization header, call supabase.auth.getUser() and use user.id. Drop user_id from the request body. Add an RLS policy on subscriptions so the database enforces it even if a function gets it wrong.
MB-06
High
Effort 3 h
No limit on text-message codes
Wheresupabase/functions/send-sms-code/index.ts
What's wrong
The phone check at checkout sends a text with a code. Anyone can ask for one, for any number, as many times as they like, without signing in.
Why it matters
Bots abuse open text-message forms to send thousands of texts to expensive numbers they profit from, and the bill lands on your Twilio account. It also makes it easy to guess codes or spam a stranger's phone.
Evidence
```
const { phone } = await req.json();       // no sign-in needed
const code = Math.floor(100000 + Math.random() * 900000);

await twilio.messages.create({
  to: phone,
  from: TWILIO_FROM,
  body: `Your Mealbox code: ${code}`,
});
// no limit per phone, per IP or per hour
```
The fix
Only send codes to signed-in customers, cap them at a few an hour per phone and per device, allow only the countries you deliver to, and set a spending alert in Twilio.
For your developer
Require a valid user JWT. Rate-limit by phone and IP (a small table with timestamps, or Upstash). Prefer Twilio Verify with Fraud Guard and a country allow-list over hand-rolled codes; if you keep your own, use crypto.getRandomValues, expire codes after 10 minutes and lock after 5 wrong tries.
MB-07
Low
Effort 3 h
Packages are behind, one with a published security hole
Wherepackage.json
What's wrong
Twelve packages are at least one major version behind. One of them, the library the app uses to call other services, is on an old version with a publicly reported security hole that's fixed in newer releases.
Why it matters
The hole is in a feature Mealbox doesn't use today, so the risk right now is low. But old packages pile up: the longer you wait, the bigger and riskier each update gets.
Evidence
```
$ npm audit --omit=dev
axios  <1.x
  1 published advisory, fixed in 1.x
  fix available via `npm audit fix --force`

$ npm outdated | wc -l
13   # 12 packages behind, plus the header
```
The fix
Update the one with the known hole now, then the rest in small groups, testing sign-up and checkout after each group.
For your developer
Bump axios to the current 1.x and check the two call sites for changed defaults. Then update in batches (Supabase client, router, UI kit), running the checkout flow by hand after each. Turn on Dependabot or Renovate so this stays small.
MB-08
Medium
Effort 5 h
When something breaks, nobody hears about it
Wheresupabase/functions/stripe-webhook/index.tssrc/pages/Account.tsx
What's wrong
When a payment update fails, the error is written to a log nobody reads, and Stripe is told everything went fine, so it never tries again. On the customer side, raw database errors are shown on screen.
Why it matters
A customer pays, the order doesn't go through, and you find out from an angry email a week later. The raw errors also tell an attacker your table and column names.
Evidence
```
// stripe-webhook/index.ts
try {
  await markOrderPaid(orderId);
} catch (e) {
  console.log(e);             // nobody reads this
}
return new Response("ok");    // Stripe won't retry

// Account.tsx
if (error) toast.error(error.message);
// 'null value in column "user_id" of relation
//  "orders" violates not-null constraint'
```
The fix
Send errors to a tracking service that emails you, tell Stripe when something failed so it tries again, and show customers a plain message instead of the database's.
For your developer
Return a 500 from the webhook on failure so Stripe retries. Add error tracking (Sentry or similar) to the app and the edge functions, with an alert on webhook errors. Map Supabase errors to friendly copy and log the original.
MB-09
Medium
Effort 10 h
Google sees an empty page
Whereindex.htmlsrc/main.tsx
What's wrong
Every page is built in the visitor's browser by JavaScript. Before that runs, the page is empty, and every page has the same title: 'Mealbox'. Google can run the JavaScript, but slowly and not always. Link previews and most AI search tools never do.
Why it matters
Your menu, pricing and recipe pages, the ones people would search for, barely show up in search results. Shared links on WhatsApp or LinkedIn show no title or image.
Evidence
```
$ curl -s https://mealbox.example/menu
<!doctype html>
<html lang="en">
  <head><title>Mealbox</title></head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index-4f9a1c.js"></script>
  </body>
</html>
# same title and empty body on all 14 public pages
```
The fix
Build the public pages (home, menu, pricing, recipes) ahead of time so they arrive with their text already in them, give each its own title and description, and add a sitemap.
For your developer
Smallest change: pre-render the public routes at build time (Vike, or a prerender step) and set per-route meta with react-helmet-async. If marketing pages will grow, move them to Next.js or Astro and keep the app behind sign-in as it is. Add sitemap.xml, robots.txt and Open Graph images.
MB-10
Medium
Effort 8 h
Slow on an ordinary phone
Wheresrc/App.tsxpublic/images/
What's wrong
The site sends 2.1 MB of code before it shows anything, because every screen, including the admin dashboard, loads at once. The photo at the top of the home page is a 3.4 MB image.
Why it matters
On a mid-range Android phone on 4G, the main content takes about 7 seconds to appear. Many visitors leave before then, and Google ranks slow pages lower on phones.
Evidence
```
Lighthouse, mobile (mid-range phone, slow 4G)

Largest Contentful Paint    6.8 s     target < 2.5 s
Total Blocking Time         1,240 ms  target < 200 ms
JavaScript                  2.1 MB    640 KB gzipped
hero-bowl.png               3.4 MB    2400 × 1600
```
The fix
Load each screen's code only when it's needed, keep the admin code out of the customer site, and shrink the photos to the size they're shown at, in a modern format.
For your developer
Route-level React.lazy + Suspense, admin in its own chunk; check with rollup-plugin-visualizer (two charting libraries and a full icon set are the biggest chunks). Convert images to AVIF/WebP with srcset, preload the hero image, lazy-load the rest. Aim for LCP under 2.5 s on the same test.

(05) Fix plan

Three weeks to ready.Riskiest work first.

Week 116 h
Security
Week 28 h
Code health
- MB-07 Packages are behind, one with a published security hole
- MB-08 When something breaks, nobody hears about it
Week 318 h
Speed and Google
- MB-09 Google sees an empty page
- MB-10 Slow on an ordinary phone

Total estimate

42 h

The fix price is fixed from this estimate and agreed in writing before I start. Fixes usually come to $1,500 – $6,000, depending on what the audit finds. The report is yours, so you can also hand it to any developer you like.

(06) Your app

Want this for your app?Send me the link.

Same report, about your real code. $500 – $1,500. Fixed price by app size, report in 3 to 5 days.

Get an audit What the audit checks

Loading page

Got an app, or an idea?

Send me the link, or a few lines about what you want to build. I'll reply within a day with honest next steps, even if I'm not the right fit.

Step 1

You send a link or an idea

A few lines is enough.

Step 2

I reply within a day

With questions or a first take.

Step 3

A free 30-minute call

Then a fixed price, in writing.

What an audit looks like.A full sample report.

This is the report you'd get for your app: a summary in plain words, a scorecard, every finding with the code that proves it, and a plan with hours.

Sample, not a client

This is a sample. The app, its founder and its numbers are made up, but every finding is a real problem I see in apps built with AI tools.

Skip to findings

-- Supabase SQL editor select tablename, rowsecurity from pg_tables where schemaname = 'public'; tablename | rowsecurity -------------+------------ profiles | false orders | false addresses | false meal_plans | true -- From any laptop, with the key from the site's JavaScript: -- curl "https://<project>.supabase.co/rest/v1/addresses?select=*" \ -- -H "apikey: <anon key>" -- → 1,240 rows, every customer's address

# .env (committed to the repo) VITE_SUPABASE_URL=https://<project>.supabase.co VITE_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs... VITE_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIs... // src/lib/adminClient.ts export const admin = createClient( import.meta.env.VITE_SUPABASE_URL, import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY, ); $ grep -c "service_role" dist/assets/index-*.js 1

Deno.serve(async (req) => { const event = await req.json(); // no signature check if (event.type === "checkout.session.completed") { await markOrderPaid(event.data.object.metadata.order_id); } return new Response("ok"); });

// src/pages/Checkout.tsx await supabase.functions.invoke("create-checkout", { body: { planId: plan.id, amount: plan.price * 100 }, }); // supabase/functions/create-checkout/index.ts line_items: [{ price_data: { currency: "usd", unit_amount: body.amount, // from the browser recurring: { interval: "week" }, product_data: { name: "Mealbox plan" }, }, quantity: 1, }],

const { user_id, plan_id, pause_until } = await req.json(); const supabase = createClient(URL, SERVICE_ROLE_KEY); // skips every rule await supabase .from("subscriptions") .update({ plan_id, pause_until }) .eq("user_id", user_id); // whoever the request says

const { phone } = await req.json(); // no sign-in needed const code = Math.floor(100000 + Math.random() * 900000); await twilio.messages.create({ to: phone, from: TWILIO_FROM, body: `Your Mealbox code: ${code}`, }); // no limit per phone, per IP or per hour

// stripe-webhook/index.ts try { await markOrderPaid(orderId); } catch (e) { console.log(e); // nobody reads this } return new Response("ok"); // Stripe won't retry // Account.tsx if (error) toast.error(error.message); // 'null value in column "user_id" of relation // "orders" violates not-null constraint'

$ curl -s https://mealbox.example/menu <!doctype html> <html lang="en"> <head><title>Mealbox</title></head> <body> <div id="root"></div> <script type="module" src="/assets/index-4f9a1c.js"></script> </body> </html> # same title and empty body on all 14 public pages

Lighthouse, mobile (mid-range phone, slow 4G) Largest Contentful Paint 6.8 s target < 2.5 s Total Blocking Time 1,240 ms target < 200 ms JavaScript 2.1 MB 640 KB gzipped hero-bowl.png 3.4 MB 2400 × 1600

What an audit looks like.A full sample report.

Is it safe to launch?The short answer first.

Eight areas, checked.Where the app stands on each.

Database access rules

Secret keys in the browser

Checks on the server

Payment webhooks

Outdated packages

Errors, logs and limits

Pages Google can render

Speed on a real phone

10 findings,each with proof and a fix.

Customer addresses and orders are readable by anyone

The database master key ships inside the website

Anyone can fake a 'payment received' message

The browser decides how much a plan costs

One customer can change another customer's subscription

No limit on text-message codes

Packages are behind, one with a published security hole

When something breaks, nobody hears about it

Google sees an empty page

Slow on an ordinary phone

Three weeks to ready.Riskiest work first.

Security

Code health

Speed and Google

Want this for your app?Send me the link.

Got an app, or an idea?

What an audit looks like.A full sample report.

Is it safe to launch?The short answer first.

Eight areas, checked.Where the app stands on each.

Database access rules

Secret keys in the browser

Checks on the server

Payment webhooks

Outdated packages

Errors, logs and limits

Pages Google can render

Speed on a real phone

10 findings,each with proof and a fix.

Customer addresses and orders are readable by anyone

The database master key ships inside the website

Anyone can fake a 'payment received' message

The browser decides how much a plan costs

One customer can change another customer's subscription

No limit on text-message codes

Packages are behind, one with a published security hole

When something breaks, nobody hears about it

Google sees an empty page

Slow on an ordinary phone

Three weeks to ready.Riskiest work first.

Security

Code health

Speed and Google

Want this for your app?Send me the link.