Sample report · AI-built app check

Booking app built with Lovable: what to fix first

This is an example of the report format. The app, its owner and its data are made up. Each finding is a kind of problem I look for in a real check, and a real report is written the same way.

Summary

A small clinic built a booking app in Lovable with Supabase and Stripe and wanted to know whether it was safe to open to customers. It works on the screen. Two problems should be fixed before anyone else signs up, because customers’ details can be read by people who should not see them. Two more should be fixed this week. One can wait.

Checked: the customer sign-up and booking path, the database rules on the four tables it uses, file storage and payment setup, using read access to the Lovable project and the Supabase dashboard. Time: about three hours.

Findings, in the order to fix them

1. 1. Fix before anyone else signs up

   Anyone can download every booking, with names and phone numbers

   What it means for you. The bookings table has its database rules switched off. Anyone who opens the app gets the key that reads it, so a stranger can download every customer’s name, phone number and appointment time without logging in. If this has already happened, it may be a data breach you need to assess.

   How I showed it. Logged out, I sent one request to the bookings table with the public key from the app’s own page source. It returned all 214 rows. Supabase’s Security Advisor lists the same table as having row level security off.

   Suggested fix and how to check it. Switch on row level security for bookings, then add a rule that lets a signed-in customer read only rows where customer_id equals their own user id. Repeat the logged-out request: it should return nothing.

2. 2. Fix before anyone else signs up

   A signed-in customer can open another customer’s booking

   What it means for you. Even with rules on, the rule on booking_notes says "true", which lets every signed-in user read every note. Customers write things like "back injury, please use the ground-floor room" in notes.

   How I showed it. I signed up two test accounts. As the second one, I changed the booking ID in the address bar to the first account’s booking and saw its notes.

   Suggested fix and how to check it. Replace the rule with one that checks the note’s booking belongs to auth.uid(). Repeat the two-account test: the second account should see an empty page or an error, not the note.

3. 3. Fix this week

   The Stripe secret key is in the app’s code

   What it means for you. The key that can issue refunds and read payment history ships to every visitor’s browser. Anyone who finds it can act on your Stripe account.

   How I showed it. Searching the built app in the browser’s developer tools for "sk_live" finds the key in one file. I did not use it.

   Suggested fix and how to check it. Create a new secret key in Stripe, move payment calls into a Supabase Edge Function that reads the key from its secrets, then delete the old key. Searching the built app for "sk_live" should find nothing.

4. 4. Fix this week

   Uploaded ID photos are in a public bucket

   What it means for you. New customers upload a photo ID. The bucket is marked Public, so anyone with a file’s link can open it, and the links follow a guessable pattern.

   How I showed it. In a private browser window, logged out, I opened a test upload’s link and the image loaded.

   Suggested fix and how to check it. Make the bucket private and serve each file through a short-lived signed link created for the signed-in owner. The same logged-out link should then fail.

5. 5. Can wait until the next round of changes

   A failed booking still says "Booked"

   What it means for you. If the connection drops while a customer books, the screen shows success but nothing is saved. They turn up for an appointment you do not know about.

   How I showed it. With the network switched off in developer tools, I submitted a booking. The page showed "Booked". No row appeared in the table.

   Suggested fix and how to check it. Only show "Booked" after the database confirms the row, and show an error that keeps what they typed if it fails.

What I did not check

• The admin dashboard, because no admin login was shared.
• Email and SMS reminders, which run in a separate automation tool.
• Behaviour under heavy load; I read the queries but did not load-test them.
• Whether you have to notify anyone about finding 1. That depends on whether data was accessed and on your business, so read the OAIC guide or ask a lawyer.

This report is not a penetration test or a security certification. Fixing these five does not mean nothing else is wrong; it means these five are known and can be closed.

Next steps

Fix 1 and 2 first and repeat the checks in each finding. The 30-minute call goes through the report and any questions. If you want me to make the changes, I quote that separately after the call.