GUIDE

Can your users see each other's data?

If your app has accounts and a database, there is one question worth more than every other security question combined: when someone logs in, can they get at anybody else's data? In apps built with AI and a hosted database, the answer is often yes, and nothing in the app looks wrong. Each person sees their own dashboard, their own list, their own uploads. The screen is filtering correctly. The database is not.

Why the screen lies

Your app is two things: the code running in the browser, and the database answering requests. When the AI builds a dashboard, it writes something along the lines of "fetch the rows belonging to the logged-in user". That is the browser asking politely. Anyone can change what the browser asks for, because it runs on their computer, not yours. Open the developer tools, edit the request, ask for all the rows instead of yours, and if the database has no rule of its own it will hand them over.

The rule that stops this lives in the database. In Supabase it is called row-level security, usually shortened to RLS, and it means each table decides for itself which rows a given person is allowed to see. Without it, the table's answer to "give me everything" is everything. This is the difference between a bouncer on the door and a sign asking people not to come in.

Test it yourself in ten minutes

You do not need to understand the code to run this test, and it is the single most useful thing you can do to an app with logins.

  1. Make two real accounts in your own app. Use two email addresses you control. Call them A and B.
  2. As A, create something identifiable: a note, a record, an upload, whatever your app stores. Put a word in it you can search for, like "zebra".
  3. Open a second browser, or a private window, and log in as B. B should see nothing belonging to A.
  4. Still as B, look at the address bar on any page that shows one item. If it has a number or an ID in it, change that to A's item. Do you get A's data or an error? An error is correct.
  5. As B, open the developer tools (right-click, Inspect, then the Network tab), reload the page, and look at the responses coming back. You are checking one thing: does any response contain the word "zebra"? If it does, B's browser received A's data, and it does not matter that the screen never displayed it.

That last step catches the case people miss. An app can hide other people's data perfectly in the interface while shipping all of it to every visitor's browser.

If the answer is yes

Do not start editing things. Ask for an assessment first, because you need to know how many tables are exposed before you change any of them.

Audit this app for data separation between users. For every table in the database, tell me in a plain table: does it hold data belonging to individual users, is row-level security enabled on it, and what policies exist. Then tell me which tables a logged-in user could currently read or write rows they don't own, and which could be read by someone not logged in at all. Include storage buckets and file uploads. Don't change anything yet — I want the list first.

Read the list. Then fix one table, starting with whichever holds the most sensitive thing, and re-run the two-account test after each one. Fixing all of them in a single pass is how people end up with an app where nobody can see their own data either, and no way to tell which change caused it.

Enable row-level security on [table name] and add policies so a user can read, create, update and delete only their own rows, identified by the logged-in user's ID. Don't touch any other table. Then tell me exactly what to click in my app to confirm it still works for a normal user, and what should now fail if I try to reach someone else's row.

The two other holes in the same wall

Row-level security only helps if the key your app ships to browsers is the restricted one. Hosted databases give you two keys: one meant to be public and bound by your policies, and an administrative one that ignores every policy you write. If the administrative key is anywhere in the code that reaches the browser, your policies are decoration. That is worth checking separately, and our plain-English guide to the two keys covers how to tell them apart. You can also point the free key-leak scanner at your live site and have it look for you.

The second hole is file uploads. People remember to lock the database tables and forget that uploaded files sit in their own storage with their own rules, often left open so that anyone with the URL can read anything. If your app accepts uploads, include storage in the audit above.

Do this before you charge anyone

An app that leaks its users' data to each other is a problem at ten users and a serious one at a hundred. The test costs ten minutes, needs no code knowledge, and tells you something that neither your AI nor your dashboard will volunteer.

When you do start changing policies, make a named copy of the working app first, so "we broke logins for everyone" is a thing you undo rather than debug. That is what Plyo does for projects built with AI: every working state saved under a name you chose, and the published version is the one you picked.

Plyo is the home for AI-built projects — every version saved, one click to undo, one click to publish, plus a safety check, visitor counts and backups. Free to start: 3 projects, no card needed.

Give your project a home