How to check your app for security holes when you're not technical

Test your app the way a stranger would. Check what it shows to someone who isn't logged in, whether one user can reach another user's data, and whether anything secret is sitting in the code your app sends to every visitor. Most of this takes half an hour in a browser; for the rest, give your AI tool or developer a precise checklist instead of "make it secure".

What a "security hole" usually looks like in a small app

Forget movie hackers. In apps built quickly, with an AI tool or by a freelancer on a deadline, holes tend to be ordinary mistakes that nobody noticed because the app still works:

• A secret key in the public code. Your app talks to other services (payments, AI, email, its database) using keys, which work like passwords. The app's public code is the set of files every visitor's browser downloads to run it. If a secret key ends up in there, anyone can copy it and use it on your bill.
• A database that answers anyone. Many AI-built apps store their data in Supabase. There, a setting called Row Level Security decides which rows of a table each person may see. If it's off, anyone holding your app's public key, which is in every visitor's browser by design, can read the whole table.
• Pages that only look private. The app hides the "Admin" button from normal users, but the admin page still opens for anyone who types its address.
• Other people's data one number away. Your order is at /orders/1042. Change it to /orders/1043 and you see someone else's order. Developers call this a broken access check; you can call it the bug you least want a customer to find.
• Leftovers. Test accounts with easy passwords, sample data, debug pages and demo keys that were "temporary".

None of these show up as an error. The app looks fine to you because you only ever use it as yourself.

Check it yourself: the stranger test

You need two email addresses and about 30 minutes. Do this only on your own app. Trying the same steps on someone else's app without permission can be illegal.

1. Create two test accounts, User A and User B, with different email addresses. Use a normal browser window for A and a private window (incognito) for B, so they stay logged in separately.
2. As User A, create something private. An order, a note, a profile, an uploaded file: whatever your app stores per person. Copy the address of the page where it shows.
3. Paste that address into a private window while logged out. You should be sent to the login page, not shown A's data.
4. Now log in as User B and paste the same address. You should see "not found" or an empty page, never A's data. If you see it, stop here: that's the hole to fix first.
5. Change the numbers. If the address has a number or code in it, like /invoice/105, try 104 and 106 while logged in as B. Every result should be B's own or nothing.
6. Try the admin pages as a normal user. Type the addresses of your admin or settings pages while logged in as B, then while logged out. Both should refuse.
7. Look for secrets in the public code. Open your live app, right-click, choose "View page source", and search the page (Ctrl+F or Cmd+F) for secret, sk_live, sk- and service_role. Not finding them here doesn't clear you: keys usually sit in separate script files that this view doesn't show, so a full search needs a tool or a developer.
8. Run the checks your tools already have. In Lovable, open the Security view and run the deep scan: according to Lovable's security documentation, the quick scan runs when you publish, while the deep scan reviews all of your app's code and only runs when you start it. In Supabase, open Security Advisor; Supabase's production checklist also asks you to turn on Row Level Security for every table and two-step login on your Supabase account.

Write down what failed and where. You'll need it in a minute.

What needs someone with access to the code

The stranger test shows you symptoms. A few things can only be checked from the inside: how the database rules are written, whether each server function checks who is calling it, and whether old keys were replaced after they leaked. If your app uses Supabase, how to check if Row Level Security is on explains the database part in detail.

You don't need to understand those parts to get them checked. Paste this into your AI tool (Lovable, Bolt, Cursor, Replit, Claude Code) or send it to your developer. A vague request like "make my app secure" tends to get a confident summary and few real changes; a list of questions gets answers you can check.

I'm not a developer. Review this app for security holes and report
back in plain language BEFORE changing anything. For each point, tell
me what you checked, what you found and how serious it is.

- Secret keys: is any secret (payments, AI, email, the database admin
  key) in code that runs in the visitor's browser? Name the file.
- Database: can each user read and change only their own rows?
  Which tables can a logged-out visitor read?
- Server functions and API routes: does each one check who is calling?
  List any that work without logging in.
- Addresses: can user B open user A's pages by changing a number or id
  in the address?
- Admin: where is "admin only" enforced: on the server, or only by
  hiding a button?
- Leftovers: test accounts, demo keys, debug pages, sample data.

Then fix the serious ones one at a time, and after each fix tell me
exactly what to click to check it worked.

When the answers come back, run the stranger test again. A hole is fixed when step 4 or step 5 stops showing someone else's data, not when the AI says "Done".

When to bring in a professional

The checks above catch the common, visible mistakes. They're not a full security review. Pay for a professional one, often called a penetration test (an expert tries to break in, with your permission), if:

• you store health, financial or children's data;
• you handle card payments yourself rather than through Stripe Checkout, PayPal or similar;
• a business customer asks you for a security report;
• your app has grown to the point where a leak would make the news in your niche.

Lovable's own documentation says the same about its scanners: apps that handle sensitive data should also get a professional security review.

Keep checking after every change

Every new prompt to an AI builder can bring a fixed hole back: a new table without protection, a new feature with its key pasted into the page. Running the stranger test once at launch isn't enough; the outside part is worth automating.

ScanYourSite is a website check made for apps built with Lovable, Bolt, Cursor, v0, Replit and Supabase. The free check needs no sign-up and takes about a minute: enter your address, or open https://scanyoursite.app/?check=yourdomain.com with your own domain in it. It looks at your live app from the outside, like a visitor's browser, and never logs in, fills in forms or guesses passwords. It finds:

• secret keys in the code your app sends to visitors, such as a Supabase admin key or an OpenAI, Stripe or Anthropic secret, and names the file they're in;
• which Supabase project your app talks to;
• missing security headers (instructions your server sends to the browser about what to block) and https problems;
• analytics or ad trackers running with no recognised consent tool, and a missing privacy policy link;
• errors in the browser's error log and files your page fails to load.

Every finding is listed with how serious it is. In the free version, the three most important come in plain words, with what they mean for you, the fix and a message you can paste into your AI tool; Pro explains all of them.

On Pro ($19 a month, three sites), after you confirm the domain is yours, it goes one step further: it counts how many rows of each Supabase table your app uses a stranger could read with the public key, without reading what's in them, and checks for files that should never be public, like .env, where secret settings are kept. Pro checks your site daily, checks within minutes of every update that it still loads and no secret key leaked, and writes only when something new is wrong.

What it can't do is steps 1 to 6 above: logging in as two different people is a test only you or your developer can run. Do that part by hand whenever you add a feature that stores something per user.