How to check in 15 minutes whether your AI-built app leaks data
By Kike Gandia · Co-Founder & CEO, OSCP
You do not need to be technical or install anything to rule out the worst flaws in an AI-generated application. You need two test accounts, a browser and a quarter of an hour. This guide is the exact procedure, step by step, with how to read each result. Always run it against your own application: running these checks against somebody else's system without authorisation is a criminal offence in Spain, whatever the intent.
What you need before you start
Three things, none of them paid:
- Two user accounts in your own application, with different data in each. Call them A and B and note what you put in each.
- The browser developer tools, opened with F12 in Chrome or Firefox. You will use two tabs: Network and Console.
- A private window, to check what somebody with no session sees.
Set aside fifteen uninterrupted minutes, and avoid peak hours if your application already has real users.
Minutes 1 to 5: what travels to the browser
Open your application with the developer tools on the Network tab and use it normally: sign in, load a screen with data, save something.
Look at the requests that appear. Look for two specific things:
Your database address. Generated applications usually show a URL from the data provider, with a long key alongside it. Being visible is normal and expected: the problem is never that it is visible, but what it allows.
Keys that should not be there. Look for strings starting with the prefixes of payment services, transactional email or third-party APIs. If a key allows charging, sending email or consuming quota, it should never travel to the browser.
Note the database address: you need it for the next step.
Minutes 5 to 10: the check that rules out the most
This is the important one. Sign out completely or open a private window, and load a screen that shows data again.
If you still see records without having signed in, the data layer is open. Anyone can request that information with the credentials you just saw in the Network tab. It is the most serious flaw on the list and requires no skill at all to exploit.
If the application redirects you to the login and returns nothing, good: there is at least an authentication control. Move to the next step, because that does not yet mean you are protected.
Minutes 10 to 15: the flaw that survives login
Now sign in as account A and find any record — a note, an order, a document. Look at its identifier: it is usually in the URL or in the request response.
Sign out, sign in as account B and request that same identifier: by changing it in the URL if it appears there, or by repeating the request from the Network tab.
If B can see A's record, your authorisation is broken. The application checks that you are authenticated but not who each piece of data belongs to. It is the second most common flaw and the most treacherous, because it slips through every functional test: each user testing their own data never finds it.
Repeat the test trying to modify or delete A's record from B. Closing reads while leaving writes open is common.
How to read what you found
| What you saw | What it means | Severity |
|---|---|---|
| Data visible with no session | The database has no access control | Critical: close it today |
| Account B sees account A data | You authenticate but do not authorise | Critical |
| Account B can edit or delete A data | Writes with no ownership check | Critical |
| Payment or email keys in the Network tab | Exposed secret, used at your cost | High: rotate it |
| An uploaded file opens with no session | Storage with open rules | High |
| None of the above | The worst configuration flaws are ruled out | Business logic remains |
A clean result is good news and not a certificate. These checks cover configuration, which is where most generated applications fail, but they do not cover your product's own logic: manipulable prices, state flows that can be skipped, or permissions that escalate through an unforeseen path. That is not visible by inspection; it has to be attacked.
FAQ
Can I run these checks on an app that already has users?
Yes, they are read-only except the last one, where you try to modify a record. Run that with your own test data, never against a real client's content, and at a quiet time. None of the five generates meaningful load or changes the application configuration.
I found a flaw, what do I do first?
Close the access before anything else: enable row-level rules that require record ownership. Then rotate any key you saw exposed, because you have to assume it may have been copied. Only then assess the scope: what data has been reachable and for how long, which is what determines whether there is a duty to notify.
Do these tests work if my app does not use Supabase?
Yes. The procedure does not depend on the provider: it checks behaviour, not technology. Firebase, Appwrite, Pocketbase or a custom backend share the same underlying model when the browser talks to the data directly, and the three possible outcomes — you see data with no session, you see other people's data, you see nothing — mean the same in all of them.
Related service
Related content
- Is an app built with AI secure?
- Supabase without RLS: why data leaks
- The 7 most frequent flaws in AI-generated apps
- A client is asking for security assurances