The fastest answer: make two accounts in your own app, open a record in one, and try to open it from the other by changing the ID in the address bar. If the second account can see the first one’s data, your app is leaking — and so is everyone else’s. That one test catches the most common serious flaw in AI-built apps. Below is the full 4-minute self-test, or paste your URL for a free check that runs all ~48 tests for you.
No code. Two logins and your browser’s address bar.
Sign up in your own app twice, with two different emails — call them A and B. Put a bit of obviously-different data in each (a note, a name, a record). Open them in two different browsers, or one normal and one incognito, so both stay logged in at once.
In account A, open one of your records. Look at the URL. If you see something like /project/1042 or ?id=1042 — that number is the record's ID. This is the single most common way AI-built apps leak data.
Now in account B's browser, paste A's URL — the one with A's ID in it. If B can see A's data, anyone can see everyone's data by changing one number. That's the flaw with the scary names: IDOR / BOLA. If B gets an error or an empty page, that door is closed.
Open your app, right-click, View Page Source (or the Network tab), and search for 'key', 'sk_', 'secret', or 'service_role'. A public key (starts pk_, or a Supabase 'anon' key) is fine — it's meant to be public. A secret key (sk_live, a service_role key) shipping to the browser means anyone can read it and spend your money or bypass your database rules.
.env file. The free check covers all of them.The most common one. Your Supabase tables are reachable with the public key and no login check (row-level security off). An estimated 7 in 10 Lovable apps fail this.
One user can see another's data by changing an ID in the URL or an API call. This is what the 4-minute test above catches.
A Stripe sk_live key or a Supabase service_role key shipped in your JavaScript — anyone who opens the source can take it.
A .env or .git left reachable at your domain hands over every secret at once.
An internal page or API route that forgot to ask 'are you allowed here?' — reachable by anyone who knows the address.
Want to see exactly how we test for each of these? Read how the check works →
Run the two-account test above: make two accounts, open a record in one, and try to open it from the other by pasting the URL with the first account's ID. If it works, your app is leaking data between users. Then check your page source for secret keys (sk_live, service_role) that shouldn't be there. For the full picture — database rules, exposed files, missing protections, spoofable email — run a free external check; it does all ~48 of these tests against your live app in about a minute.
Yes — and more often than hand-written ones. The builder writes working code fast, but 'working' and 'secure' are different things: independent 2026 research found AI agents implement a requested feature about 61% of the time but only get it secure about 10% of the time. The most common result is a database left open to the public and data that leaks between users. Nothing about being no-code or AI-built protects you; if anything the defaults are riskier.
The two-account ID-swap test needs no code — just two logins and your browser's address bar. It catches the single most common serious flaw. The key check needs one View-Source. Beyond that, an external check is the non-technical option: you paste your URL, it runs every test, and you get a plain-English grade with exactly what's exposed and how to fix it.
Testing your own app is entirely fine — it's your app and your accounts. The external check is read-only: it looks at your live site the way any visitor would and never changes anything or logs in. Don't run these tests against an app you don't own.
Don't panic — these are common and fixable. If it's a secret key in the browser, rotate it now (generate a new one, update your app, revoke the old). If it's an open database or an ID-swap leak, that's a database-rules (RLS) and authorization fix. You can hand the exact findings to your AI builder with a fix prompt, or have a senior dev fix and verify it for you — that's what the Production-Ready package is for.
Every test above, run against your live app in about a minute — with a plain-English grade and exactly how to fix what it finds.