Why can one user see another user's data?

Is this a data breach?

If someone who should not have been able to see personal data was able to see it, then yes — treat it as one until you have evidence otherwise. It counts whether or not anyone acted maliciously, and whether or not the person who found it was a customer being helpful. Intent is not part of the definition.

The distinction that matters for what you do next is exposure versus access. Exposure means it was possible. Access means it happened. Your logs decide which one you have, which is why the first move is to look rather than to patch — patching first can destroy the evidence that would have told you the scope.

How do I check whether this is happening in my app right now?

Sign up two accounts in two different browsers. Create something in the first account — an order, a document, a project — and note the id in the URL. Then, signed in as the second account, put that id in the URL and press enter. If you can see it, you have reproduced the problem, and you did not need any tools to do it.

Then repeat it for the other three actions, because they fail separately: try to edit it, try to delete it, and try to include it in any export or report. It is completely normal to find that reading is properly locked down and deleting is not.

Do this test signed in as a real second user, through your app, exactly as a customer would. Testing from your database dashboard or with an admin key proves nothing — those bypass the rules by design and will make a broken app look fine.

Why do AI-built apps get this wrong so often?

Because nobody asks for it. You asked for a dashboard that shows a customer their orders, and you got one. You did not ask for "and make it impossible for a different customer to open this page" — and an AI builder will not invent a requirement you never stated. The feature is what gets specified; the restriction is what gets assumed.

It is worth being clear that this is not a defect in the tool, and it is not carelessness on your part. It is a gap in the request. Working software and safe software are two different specifications, and only one of them is visible when you click around your own app as its owner.

Do I have to tell my customers?

Often yes, and the obligation is usually faster than people expect. Under GDPR you must notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware — unless the breach is unlikely to result in a risk to people's rights and freedoms. Under India's DPDP Act you must intimate both the Data Protection Board and every affected person, with no minimum size threshold.

India's rules are specific about sequence: tell affected people without delay through their account or a registered contact method, give the Board an immediate description of the breach, and follow it with a fuller report within 72 hours.

This is a summary of published law to help you understand the shape of the obligation — it is not legal advice, and which regime applies depends on where your users are, not where you are. If real personal data was reachable, talk to a lawyer the same day.

It only happened to one user — is that still serious?

Almost always, yes, because one user seeing one record is rarely the actual scope. The same missing check usually applies to every record in that table — what varies is only who happened to try. Assume the ceiling is "every row" until your logs show otherwise.

The reasoning that gets people into trouble here is treating the one report as the scope. The customer who wrote in found it by accident, which tells you it was easy to find, not that it was rare.

Can I fix this myself?

The ownership check usually yes — comparing the signed-in person against the owner of the record is a small, well-documented change with a clear finish line. Database access rules are the ones worth getting help with, because they fail silently in both directions: too loose and everything leaks, too tight and your app quietly shows empty pages.

Whatever you do, do not fix it by turning the rules off to make the app work again. That converts a scoped problem into a total one. If your app goes blank after you enable protection, that is the safe failure — it means the rules are on and the policy you meant to write is missing.

Tool-specific detail: Lovable, Bolt.new, v0. If your data is in Supabase, the Supabase RLS checklist is the mechanism in full.

How do I stop it coming back?

Make the two-account test part of shipping rather than a thing you did once. Every time you add a table or a page that shows somebody their own records, create the second account and try to reach the first account's data. It takes about two minutes and it is the only check that tests the thing you actually care about.

The durable version is to make the rule live in the database rather than in each screen. Rules written per-page have to be remembered every time anyone adds a page; a rule in the database applies to screens that do not exist yet. This is the second of the seven layers.