Your AI-built app passes login. Can it keep accounts apart?

Your app lets people create an account and sign in to a dashboard. That makes a convincing demo. It doesn't answer a harder question: what happens when one signed-in user asks for another user's private record?

Signing in proves who someone is. It doesn't decide what they are allowed to open. Auth0 calls the two parts (opens in a new tab) authentication and authorization, and an app built with AI tools needs both, like any other app.

A check you can run yourself

You need a browser and two test accounts. Use a test copy of the app if you have one, and only invented data.

• Create accounts A and B. Give each a private record with made-up details you will recognize.
• Signed in as A, open A's record and copy the web address from the address bar.
• Sign out, sign in as B, and paste that address.

If B can see A's record, stop there and keep real customer data out of the app until it is fixed. If B is refused, that is a good sign, but the screen can hide a record the server would still send. If your app never shows a record's address, go straight to the developer check below.

The check passes when B is refused every way it asks for A's record and can still open its own. That covers one boundary that matters. Other launch risks need their own checks.

For your developer

Send B's request for A's record straight to the server, skipping the app's screens, and repeat it for editing, exporting, and deleting. OWASP calls this flaw (opens in a new tab) broken object level authorization. Hard-to-guess record IDs make the flaw harder to exploit without fixing it.

The fix belongs on the server. OWASP's guidance (opens in a new tab) is to deny access by default and check permission on every request. Make the two-account test an automated test that runs with each change, and keep the allowed request in it so that blocking everything cannot pass.