IndustriesWorkPlaybookHow it worksAboutBook a systems auditBring us your idea

Playbook  /  Is it safe: security and risk

How do I know if my app is leaking data?

Straight answer

You check the places data leaks from: the page source, the network requests, your database access rules, and what a logged-out visitor can reach. Open your own app, look for exposed keys and readable records, and try to see data you should not. If you can reach it, so can a stranger.

Information current as at 5 July 2026

A data leak rarely announces itself. There is no alarm, no error, no obvious sign; the app keeps working perfectly while quietly handing out information it should be guarding. The good news is that many leaks are findable with a browser and twenty minutes, using the same tools anyone probing your app would use. Here is how to look, in the right order.

Plain English
Page source
The underlying code of a web page, viewable by anyone, where secrets sometimes hide.
Network tab
A browser panel showing every request your app makes and the data it sends back.
Endpoint
A specific web address your app calls to fetch or save data.
Row-level security
Database rules that limit each user to only their own records.

Step by step

  1. Read your own page source for secretsOpen your app in a browser, right-click and choose View Page Source, or open the developer tools. Search the text for words like key, secret, token, and password. Nothing that grants access to a service or database should ever appear here, because anyone in the world can read this. If you find a live key, treat it as exposed: it needs resetting and moving into a server-side setting. This is the fastest, highest-value check you can do, and it needs no technical background.
  2. Watch the network tab as you use the appOpen the developer tools, go to the Network tab, and click through your app while it records. Each entry is a request your app made. Click a few and look at what came back. The question is whether any response contains more than the current user should see: other people's emails, full records, admin-only fields. Apps often fetch everything and hide the extra in the browser, which means it was never actually hidden. If the data is in the response, it has already left your control.
  3. Try to reach data while logged outLog out entirely, or open a private browser window, and try to visit pages and data that should require a login. Copy an address that shows a record when you are logged in, then load it while logged out. If it still returns the data, your access is not really enforced. A login page that hides a screen but does not protect the data behind it is a common and serious gap, because the protection was only visual.
  4. Test whether one user can see another user's dataMany records are fetched by an identifier in the address, often a number or a code. While logged in as one user, change that identifier to another value and see what loads. If you can view someone else's order, profile or message by editing the address, the app is trusting the browser to ask nicely rather than checking who is allowed. This is one of the most frequent leaks in AI-built apps, and one of the most damaging.
  5. Check your database access rules directlyLog in to your database service, often something like Supabase, and find the access or security settings. Confirm that row-level security or equivalent access rules are switched on and actually written, not left in a permissive default. An open database is a leak waiting to be found, whatever the app in front of it does. If you cannot tell whether the rules are protecting anything, assume they are not, and treat closing that gap as the priority.
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Common questions

Questions, answered

Is it legal for me to poke at my own app like this?
Yes. It is your app and your data, and checking your own system for leaks is exactly what you should do. The techniques are the same ones anyone could use against you, which is the point: you want to find the gaps first. Do not test systems you do not own.
I found a key in my page source, what now?
Treat it as compromised immediately. Reset or regenerate that key in the service it belongs to, so the exposed one stops working, then store the new one as a server-side setting rather than in code the browser can read. Assume the old key was seen, even if you have no evidence it was used.
What if I can see another user's data by changing the address?
That is a real leak and a priority fix. The app is checking who you are to log you in, but not checking whether you are allowed to see each specific record. The data access rules need to be enforced on the server for every request, not assumed. This is a common gap worth getting help closing.
How often should I run these checks?
Do a full pass before launch and after any significant change, especially changes to logins, data, or who can access what. A quick page-source and logged-out check takes minutes and is worth repeating whenever you add a feature that touches customer information. Leaks often appear when new functionality is bolted on.
Keep reading
Is my AI-built app secure? →What is an exposed API key and why it matters? →Is it safe to store customer data in my app? →systems-audit →All playbook articles →
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Start here

Two doors. Same senior team.

Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.