Hackers Don't Hack AI-Built Apps. They Just Log In.

There is a move that gets into more apps than any exploit ever written, and it does not deserve the word hack.

You sign up for the app like a normal customer. Free account, real email, nothing shady. You open something of your own, an order, a profile, an invoice, and you look at the address bar. There is a number in it. Something like /orders/1042. You change it to /orders/1041.

And now you are reading somebody else's order.

No exploit. No malware. No hoodie. The app handed the data over, politely, because nobody ever told it not to. If your app has this hole, every URL is a menu, and the menu includes all of your customers.

The lock is on the wrong door

Here is the mental model that makes this click. A login answers exactly one question: who are you. It says nothing about what you are allowed to see. Those are two different jobs, and the second one has to happen on every single request. Is this user allowed to see this record. Miss that check and the login is a lock on the front door of a house with no interior walls.

I have been writing software for 13 years, and I can tell you this is not a beginner mistake that professionals age out of. Big companies ship it. It is just that AI-built apps ship it more, and there is a specific reason why.

Why your AI left it open

You said "build me a login." It built you a login, probably a decent one. What you never said was "and on every request, check that the person asking is allowed to see the thing they asked for." So that check does not exist. The AI builds exactly what you ask for. It does not build what you forgot to ask for.

I said this in the video and I will stand on it: unless you specifically ask, what the AI hands you is a demo-ready product. A demo has one user, you, looking at your own data, and everything works great. Production has strangers. And one of them, eventually, is curious about what happens when the number in the URL goes down by one.

The boring name, and why it should scare you a little

This hole has a name: broken access control. OWASP, the group that tracks how web applications actually get broken, ranked it the number one web application risk in 2021. In their new 2025 list, it is number one again. Out of everything they measured, it had the most occurrences by far, about 1.8 million of them, across more than 32,000 known vulnerabilities. They even widened the category this year to explicitly include the change-a-number move, which the industry calls BOLA. You can read the write-up on the OWASP site.

Number one, two lists in a row, and it is the attack that requires no tools and no skill. That combination is why I keep making noise about it.

Check your own app in five minutes

You do not need a security background to test for this. You need a second browser tab.

1. Change the number. Log in as yourself, open something that belongs to you, and change the ID in the URL. If you can see another user's data, you have the hole. That is the whole test.
2. Log out and paste. Copy that same URL, log out, paste it into a fresh tab. You should get bounced to a login, not shown the data.
3. Ask the server directly. The page hiding a button is not the same as the server refusing the request. Open your browser's dev tools, find the API call the page makes, and try it with the other user's ID. The server itself has to say no.
4. If you are on Supabase or anything like it: check that row-level security is on, and then read the actual policy. A policy that says "allow everyone" with the switch flipped on is protection in name only. I have made that exact mistake myself.
5. Try a normal account on the admin pages. If /admin opens for a regular user, same hole, bigger blast radius.

If you want the full version of this, I built a free readiness check you can run on your build right now. Twenty-one questions, takes a few minutes, gives you a score out of 100 and flags the deal-breakers. No email needed for the check itself.

The question you have to ask

If you take one thing from this, take the habit, because it is the same habit that fixes every hole like this one. Security is a question you have to ask, not a feature the AI adds on its own. Before real people's data goes into your app, say to your AI: "for every request, check that the signed-in user is allowed to see the record they asked for, and show me where that check happens."

Then change one number in a URL and try to rob yourself. It is a strange feeling the first time you get in. It is a much better feeling than reading about it in your inbox from someone else.