Sample AI app audit: full report

An audit of an open-source ordering app built with Lovable, React and Supabase: 21 findings, the 5 worst risks in plain words, and what to fix first.

1. Cover

This is a sample. The app is a public open-source project, and its name and author are removed, together with the admin email and password it exposes. File names, line numbers and code names are left out too, so the app cannot be traced. The paid report gives the exact file and line for every finding. A paid audit also covers the live app, the database settings and the deploy setup, with the owner's access.

2. Summary for the founder

Verdict: fix it. Nothing needs a rebuild. The bones are good: every table has row level security turned on, prices are worked out on the server and not trusted from the browser, the Stripe webhook checks its signature, and TypeScript runs in strict mode. The problems are a handful of shortcuts, and most take under half a day to close.

The 5 worst risks, in plain words

1. Anyone can log in as the admin. The staff sign-in page fills in the admin email and password for you and prints them under the form. That account can see every guest's name, phone number and email, and change prices or hide and delete menu items.
2. Anyone can create an order marked "paid". The database lets any visitor write straight into the orders table, past the app, and choose every field, including "paid" and the total. The kitchen screen then shows it as "Paid online". That is free food.
3. The web framework has a known critical security hole. The version of TanStack Start in use has a published cross-site scripting advisory. Staff login sessions live in the browser's storage, which is exactly what such a hole can steal.
4. Bots can flood the kitchen. Orders, table requests and sign-ups have no rate limit and no bot check. A simple script can fill the order screen with fake dine-in orders during a lunch rush.
5. An order can show "paid" before the money arrives. The payment handler marks an order paid when checkout finishes, without checking that the payment actually went through. For slower payment methods those are 2 different moments.

Fix this week, before anything else

1. Remove the demo login from the sign-in page and change the admin password.
2. Stop visitors from writing to the orders, order items and reservations tables directly. Only the server should write there.
3. Update TanStack Start and its serializer to the fixed versions.

All 3 together are about 2 days of work.

3. How I checked

Every finding below comes from the code itself, with the file and line where it lives. Nothing was guessed from the outside, and nothing was tried against the live app.

4. Findings at a glance

21 findings: 2 Critical, 4 High, 9 Medium, 6 Low.

Severity: Critical is a data leak or money at risk; fix before the next user signs up. High breaks things for users or blocks growth. Medium slows every future change. Low: clean up when you are in that code anyway. Effort: S is under half a day, M is half a day to 2 days, L is more than 2 days.

5. Every finding in detail

Each finding has where it lives, what the code does, why it matters, how to fix it and how to check that the fix works.

1. Anyone can log in as the admin

What I found. The sign-in form keeps its email and password in React state, and both start with the admin's real values. Under the form, the page prints the same email and password as "Demo access (temporary)". One of the database migrations looks up that email among the login accounts and gives it both the admin and the staff role.

Why it matters. A stranger opens the staff page, presses Sign in and lands on the staff dashboard. There they see every reservation with name, phone, email and notes, and every order with name, phone and table. The same account can edit prices, mark items sold out, hide them and delete them. If the cafe is in the EU, names, phone numbers and emails are personal data under the GDPR, and a leak like this may have to be reported.

How to fix it.

1. Start both fields empty.
2. Delete the "Demo access" line.
3. Change the admin password in the Supabase dashboard today, before the code change goes live.
4. Read the Supabase auth log for sign-ins to that account from unknown places since the app went live, and tell the owner what was found.

How to check the fix. Open the sign-in page in a private window: both fields are empty and no credentials are printed. Signing in with the old password fails.

2. Anyone can create an order marked "paid"

What I found. A migration grants insert rights on the orders and order items tables to anon, the role every visitor has, and the insert rules use WITH CHECK (true), so every column can hold any value. The public Supabase key is in the browser bundle, as it is in every Supabase app, so any visitor can talk to these tables directly. The app's own order function also writes with the public key, which is why the open rule exists: the server itself needs it.

Why it matters. The order function works out prices on the server, but a direct write skips it. Someone can save an order with the payment status set to paid, any total, and items at any price. The staff screen lists every order that is not waiting for payment and labels this one "Paid online". The kitchen makes it, the counter hands it over.

How to fix it.

1. Change the order function to write with the server-only database client, which already exists in the code. A single database function that saves the order and its items is an equally good choice and also fixes finding 9.
2. In a new migration, drop both insert rules and revoke insert rights on both tables from anon and authenticated.
3. Keep the payment status writable only by the server: new orders start as waiting for payment or pay at the counter, and only the webhook sets paid.

How to check the fix. With the public key, a direct insert into the orders table returns a permission error. Placing a dine-in and a takeaway order through the site still works, and a test payment still turns the takeaway order to paid.

3. The web framework has a known critical security hole

What I found. @tanstack/react-start is pinned to exactly 1.168.32, with @tanstack/start-server-core 1.169.17 under it. OSV.dev lists GHSA-qx66-fv34-fjm8 for both: reflected cross-site scripting in server function responses, rated critical, fixed in 1.168.60 and 1.169.39. The serializer seroval 1.5.6 has GHSA-p6vx-979v-rg4c (critical) and GHSA-jp82-f5mq-hwhp (high). zod 3.25.76 has GHSA-mrhx-c7xc-m3w5 (high, memory use). The full list is in section 6.

Why it matters. The Supabase client stores the staff login session in localStorage. Any script that runs on the page can read it. A staff member who opens a crafted link hands over their session, and with it everything in finding 1.

How to fix it.

1. Update @tanstack/react-start to at least 1.168.60 and let @tanstack/start-server-core, seroval and zod move to their fixed versions.
2. Run the build and click through ordering, payment and the staff dashboard, since TanStack Start changes quickly between patches.

How to check the fix. Run the same OSV.dev check on the new bun.lock: no critical or high advisories left in packages that reach the browser or the server.

4. Fake confirmed bookings

What I found. Same pattern as finding 2: insert rights for anon and an insert rule with WITH CHECK (true). The server's form check only runs when the app's own form is used. The database allows the statuses pending, confirmed and cancelled, so a direct write can choose confirmed.

Why it matters. Staff see bookings that look already confirmed by someone on the team, and hold tables for people who do not exist.

How to fix it. Write reservations from the server with the server-only client, then revoke insert rights from anon and authenticated. If the open rule has to stay for some reason, at least limit it to new requests with the status pending.

How to check the fix. A direct insert with the public key fails. A table request through the site still arrives as pending.

5. Bots can flood the kitchen

What I found. A search of the whole code finds no rate limit, no captcha and no bot check. Dine-in orders are saved as pay at the counter and appear on the staff screen straight away, with no payment step in between.

Why it matters. The order form takes up to 30 items per order and has no limit on how often it is sent. A short script can put hundreds of fake dine-in orders on the kitchen screen in a minute, right at lunch, and fill the reservation list the same way.

How to fix it.

1. Add Cloudflare Turnstile to the order form, the table form and sign-up, and check its token on the server in each of the 3.
2. Add a simple per-visitor limit on the 2 public server functions, for example 5 orders and 3 table requests per 10 minutes from one address.
3. Turn on the rate limits and captcha in the Supabase auth settings.

How to check the fix. Sending the order form 10 times in a row from one browser gets refused after the limit, and a request without a valid Turnstile token is rejected by the server.

6. An order can show "paid" before the money arrives

What I found. The webhook treats checkout.session.completed and checkout.session.async_payment_succeeded the same way and marks the order paid for both. It never reads the session's own payment_status.

Why it matters. For card payments the 2 moments are the same. For delayed methods (bank debits and similar, if they are ever switched on in Stripe), Stripe sends checkout.session.completed with payment_status set to unpaid, and only later sends async_payment_succeeded or async_payment_failed. The kitchen screen says "Paid online" for an order that may never be paid.

How to fix it. On checkout.session.completed, mark paid only when the session's payment_status is paid. Keep async_payment_succeeded as the second way to become paid, and async_payment_failed as failed.

How to check the fix. With the Stripe CLI, send a test checkout.session.completed event with payment_status unpaid: the order stays waiting for payment. Send async_payment_succeeded: it becomes paid.

7. The checkout price can differ from the cart

What I found. Checkout is created with automatic_tax[enabled]=true. The cart total and the saved order total are both the plain sum of the items, without tax.

Why it matters. Where tax is added on top, the customer sees one price in the cart and a higher one at Stripe, which looks like a trick and loses orders. If Stripe Tax is not set up on the Stripe account, Stripe refuses to create the checkout. The customer then sees a "could not start the payment" error on every takeaway order, and an unpaid order is left behind in the database each time.

How to fix it. Ask the owner whether menu prices already include tax. If they do, which is normal for cafes in Europe, remove the automatic tax setting. If they do not, show the tax in the cart before checkout and save the final amount from Stripe on the order.

How to check the fix. Place a takeaway order in Stripe test mode: the amount on the Stripe page matches the cart to the cent.

8. A paid order can jump back to "new"

What I found. When a payment arrives, the webhook also sets the kitchen status back to "new", and it does this by order id, whatever state the order is in. No event id is stored, so the same event is handled again each time it arrives.

Why it matters. Stripe can send an event more than once, and retries it when the webhook is slow to answer. If the kitchen has already moved the order to "preparing" or "ready", a repeat puts it back to "new", and it can be made twice.

How to fix it. Only update orders that are not paid yet, and leave the kitchen status alone when the order already moved on. Store each processed Stripe event id in a small table and skip ids already seen.

How to check the fix. Send the same test event twice with the Stripe CLI after moving the order to "ready": it stays "ready".

9. An order can be saved without its items

What I found. The order is saved first and the items in a second, separate write. If the second write fails, the function returns an error to the customer but leaves the order in the database. The Stripe session reference is saved afterwards without looking at the result.

Why it matters. A dine-in order with no items appears on the kitchen screen. The customer, told it failed, sends it again. And when the payment reference is not saved, the payment is hard to match to its order when a refund or a dispute comes in.

How to fix it. Save the order and its items in one database function, which runs as 1 transaction: both are saved or neither is. Check the result of the payment reference write and log any failure.

How to check the fix. Force the item write to fail in a test (for example a quantity of 0): no order is left behind.

10. Two orders can share a pickup code

What I found. The pickup code is the first 6 characters of a random id, each from 16 possible values: 16,777,216 codes in total. The code column has no unique rule. The order status page looks the code up with .maybeSingle(), which returns an error when 2 rows match, and the page then says the order was not found.

Why it matters. Codes clash much sooner than the total suggests (the birthday problem): after about 4,800 orders there is a 50% chance that 2 orders share a code. That customer's status page says "Order not found" while they wait at the counter.

How to fix it. Add a unique index on the code and try a new code when the save hits it. Or use 8 characters, which pushes the 50% point to about 77,000 orders, and still add the unique index.

How to check the fix. Saving 2 orders with the same code in a test is refused by the database, and the server retries with a new code.

11. Tables can be booked for closed hours and past dates

What I found. The server checks the date only against the pattern \d{4}-\d{2}-\d{2}. The "not in the past" rule exists only in the browser form, so it is skipped by any direct request. The time slots are 08:00 to 17:00 for every day of the week, while the opening hours on the homepage end at 4:00 PM on Sunday and 5:00 PM Monday to Wednesday. There is no limit on bookings per slot. A date that matches the pattern but does not exist, like 2026-99-99, reaches the database and comes back as a general error.

Why it matters. Guests can ask for a table at 17:00 on a Sunday, an hour after closing, or for yesterday. Staff have to sort these out by phone, and busy slots can be booked far past the room's size.

How to fix it. Keep one list of opening hours and use it for both the homepage and the server. On the server, check that the date is real, not in the past, within opening hours for that weekday, and under the number of guests the room holds for that slot.

How to check the fix. A request for yesterday, for a closed hour, or for a full slot gets a clear message, and nothing is saved.

12. No password reset, and anyone can sign up

What I found. The Supabase password reset (resetPasswordForEmail) is not called anywhere in the code, and there is no page to set a new password. The staff sign-in page has a "Create account" tab open to anyone. New accounts get no role, which is correct, and see a "no staff access yet" message.

Why it matters. A staff member who forgets the password is locked out until someone changes it by hand in Supabase. The open sign-up tab adds accounts nobody needs and, with no bot check (finding 5), invites spam.

How to fix it. Add a "Forgot password" link and a page to set the new one. Turn off public sign-up in Supabase and add staff by invite from the dashboard.

How to check the fix. The reset email arrives and the new password works. The "Create account" tab is gone, and a direct sign-up call is refused.

13. The setup guide gives a broken app

What I found. The example settings file names the public key differently from the name the code reads. The server key (SUPABASE_SERVICE_ROLE_KEY) is missing from the example, but the code needs it for the order status page and the webhook. The README tells a new developer to copy the example file. There is no CI, no staging, and the repository's notes for AI agents say every commit to the connected branch syncs back to Lovable.

Why it matters. A developer who follows the README gets an app where the order status page and the payment webhook fail. Any change, from a person or from the AI builder, reaches customers with no build or test step in between, and there is no written way back.

How to fix it. Correct the names in the example file and add the server key with an empty value. Add a CI step that runs the type check, the existing lint script and the tests from finding 14 on every push. Write down how to roll back to the last good version.

How to check the fix. A fresh copy set up only from the README places an order and shows its status page.

14. No tests

What I found. The project has scripts to run, build, preview, lint and format. There is no test script and no test file.

Why it matters. Every change to ordering or payments is checked by clicking through it, or not at all. Findings 6, 8 and 9 are exactly the kind of mistake a test catches before customers do.

How to fix it. Add Vitest and write tests for the order function (prices come from the database, a sold-out item is refused), the webhook (paid, unpaid, repeated event) and the signature check (good, wrong and expired signature).

How to check the fix. The tests run in CI and fail when one of these paths breaks.

15. The same code in many places

What I found. The small fetch wrapper that fixes the Supabase key header is copied into 6 files. A shared helper was written to replace the copies and is never imported. The 4 menu categories are typed out in 8 places, one of them a database check.

Why it matters. A fix to the wrapper has to be made 6 times, and one missed copy is a bug that shows up in only one part of the app. A new category ("Drinks") means 8 edits and a migration.

How to fix it. Use the one shared helper everywhere and delete the copies. Keep the categories in one exported list, or in a small table the staff can edit.

How to check the fix. A search for the wrapper finds 1 copy, and the categories list is defined once.

16. A broken menu looks like an empty menu

What I found. When the menu query fails, the server logs the error and returns an empty list. The homepage then shows "No items in this category yet."

Why it matters. During a database problem, visitors see a cafe with nothing on the menu and leave. No one on the team is told.

How to fix it. Let the error reach the page, show "The menu did not load" with a retry button, and send the error to a log the owner sees.

How to check the fix. With a wrong database address in a test, the page shows the error and the retry button, not the empty message.

17. The settings file is in git

What I found. .env is tracked in git although .gitignore lists it, and the README says only the example file is committed. Today it holds only the public Supabase keys and the project id, which are safe to share. I searched every commit: no real secret was ever in it.

Why it matters. The next person who adds a Stripe key or the service key there, trusting the README, publishes it in the git history for good.

How to fix it. git rm --cached .env and commit, so the file stays on disk but leaves git.

How to check the fix. git ls-files .env returns nothing.

18. Unused UI components

What I found. The generated UI kit was added in full. 33 of its 46 files are not imported anywhere. 7 packages are used only by those files: cmdk, embla-carousel, input-otp, react-day-picker, react-resizable-panels, recharts and vaul.

Why it matters. The build drops unused code, so visitors do not pay for it. The team does: more files to read, and 7 more packages to keep updated and to check for advisories.

How to fix it. Delete the unused files and remove the 7 packages.

How to check the fix. The build still passes, and every page looks the same.

19. The menu reloads every 30 seconds

What I found. The menu query uses refetchInterval: 30_000 and refetchOnWindowFocus: true.

Why it matters. Each homepage left open on screen calls the server and the database about 120 times an hour, and again every time the visitor switches back to the tab. The menu changes a few times a day at most. Small now. With traffic, it shows up on the hosting and database bill.

How to fix it. Reload every 5 minutes, or drop the timer and reload only when staff change the menu.

How to check the fix. With the page open for 10 minutes, the network tab shows 2 menu calls or fewer, not 20.

20. Loose types and a false "done" message

What I found. The database client is typed as any in 2 places, so the type checker cannot catch a wrong table or column name there. Every staff action checks the staff role first, except the one that confirms or cancels a reservation. For a signed-in user without the staff role, the database rule blocks the change correctly, but it returns no error, so the page shows a success message for a change that did not happen.

Why it matters. No data is at risk, since the database rule holds. It is a hidden source of type errors and a message that tells the truth only to staff.

How to fix it. Type the client with the generated database types, and add the same staff check to the reservation action.

How to check the fix. The type check passes with no any left in those places, and a non-staff user gets a refusal, not a success message.

21. Dollars are hard coded

What I found. Prices are formatted with a $ sign, and Stripe is always asked for usd.

Why it matters. A cafe in the euro area, or anywhere outside the US, needs code changes before it can take a single payment in its own currency.

How to fix it. One currency setting, used both by Stripe and by a price format based on Intl.NumberFormat.

How to check the fix. Changing the setting to eur shows "€4.50" in the cart and charges in euros in Stripe test mode.

6. Dependency advisories

From the OSV.dev check of all 482 locked package versions in bun.lock. The first 4 rows reach the browser or the server. The rest run only on the developer's machine or during the build.

Updating TanStack Start (finding 3) moves most of these along with it.

7. What is done well

Worth saying, because it is why the verdict is fix and not rebuild.

8. What I could not check

A sample uses the public code only. A paid audit closes these with the owner's access.

1. The live database. Rules can be changed in the Supabase dashboard after the migrations, so the live rules may differ from the code. The auth settings (email confirmation, captcha, rate limits, leaked password protection) are unknown.
2. Whether the demo admin login still works on the live app. Not tried on purpose: no login attempts on an app I do not own.
3. Stripe. Whether keys are set, which payment methods are on, and whether Stripe Tax is set up (finding 7).
4. Speed on a phone. Lighthouse and the real bundle size need a build.
5. ESLint and type check results. Both need an install.
6. Hosting. Lovable and Cloudflare settings, logs, backups and rollback.

9. Fix or rebuild

No part costs more than half of a rebuild to fix, so nothing is rebuilt.

10. Next step

Fixed prices, in order of severity.

Why the low end of the 3,000 to 8,000 EUR range: the app is small (about 4,300 lines of its own code), the structure is sound, and most fixes are small and local. Step 1 can start alone, so the 2 risks that hurt most are closed within the week.

Matjaž Korošec (koroCode)

← Back to the summary