If I could only check one thing on a newly built app, it would be this one. Not because it is the most sophisticated failure, but because it is the most common, the most damaging, and the most completely invisible from the inside.
Here it is in one sentence: a lot of AI-built apps will happily hand customer A's data to customer B, and sometimes to someone with no account at all.
How does that happen if I added login?
Because "has an account" and "is allowed to see this particular record" are different checks, and only the first one is obvious.
Picture an app with a page at /invoice/41. You log in, you see your invoice. Perfect. Now change the number to 42. If that loads somebody else's invoice, the app checked that you were logged in and never checked that the invoice was yours.
It is an easy thing to miss because nothing looks wrong. You only ever had one account while you were building, so there was no second customer whose data could appear. The fault needs two customers to become visible, and it arrives on the day you get your second one.
The more alarming version
Some apps built on hosted databases do not even need the login step. The tools that make it quick to get started often expose the database directly to the browser, and then rely on rules you are supposed to write to say who can read what.
If nobody wrote those rules, the default on some platforms is everything is readable. Not by hackers. By anyone who opens the developer console, which is a menu item in every browser on earth.
This is not a rare misconfiguration. It is the single most reported class of leak in the current wave of AI-built software, and the reason it keeps happening is that the app works beautifully either way.
The two-minute check
You do not need me for this.
- Log into your app and find a page showing something private — an order, a record, a document.
- Copy that page's full address.
- Open a private browsing window, where you are not logged in.
- Paste the address in.
If you can see the content, you have your answer, and you should not put a customer on that app until it changes.
Then do the second version: make a free second account, log in as that, and paste the first account's address. If account two can read account one's data, same answer.
That is it. No tooling, no code, no consultant.
If you find something
Do not panic and do not rewrite the app. This is usually a contained fix — a set of rules saying "a row belongs to the account that created it, and only that account may read it" — and on most platforms it is a day's careful work rather than a rebuild.
What it is not is something to put off until after launch. The window where this is cheap to fix is exactly the window where you have no customers, which is now.
And if it passes?
Good. Genuinely. Then the next questions are where your secret keys live, and whether anything would tell you if the app broke overnight. But you will have cleared the one that does the most damage.
I audit software for a living and I am still slightly amazed at how often this single check is the whole story.
Run the free website check — a public endpoint that drives a real browser at whatever address a stranger gives it, which carries its own version of this problem and has the boundary and tests that implies.
If you ran the check above and did not like what you saw, tell me what you found. I am one engineer; if it is a day's work I will tell you that rather than scope a project around it.
