Test That One User Can't See Another User's Data (Base44)

The quickest way to test whether your Base44 app leaks data is to log in as one user, copy the address of one of their records, then open that address while logged in as a different user. If the second user can see it, your app has a data access problem. It takes about ten minutes, and you don't need to read any code.

Data access is the check founders skip most, because the app looks fine when you click around as yourself. This guide walks through the test step by step, shows how to read the result, and tells you what to do if something opens that shouldn't.

Why one user can sometimes see another user's data

Most apps list "my" records on a page: my orders, my projects, my invoices. The page may only show your records, but the data behind it can still be reachable by anyone who knows or guesses the address of a record. Hiding a button is not the same as blocking access.

When an AI builder creates a page, it usually makes the screen work first. Rules about who may read each record are a separate setting, and they are easy to leave open. The test below checks the rules, not the screen.

What you need before you start

• Two test accounts. Use two email addresses you control, for example a "user A" and a "user B". Both should be normal users, not admins.
• At least one record created by user A (an order, a project, a note, whatever your app stores).
• A second browser profile or a private window, so you can stay logged in as both at once.
• A notes file to write down what you try and what happens.

The wrong-user test, step by step

1. Log in as user A in your main window and open one of their records. Copy the full address from the address bar.
2. Log in as user B in a private window.
3. Paste user A's address into user B's address bar and press Enter.
4. Write down what you see. Three outcomes are possible:
   • A "not found", "no access", or a redirect to a safe page: good.
   • A blank page with no data: probably fine, but check the next section.
   • User A's record, even partly: a problem to fix before launch.
5. Repeat for each kind of record your app stores. A pass on orders says nothing about invoices or messages.

Check the less obvious places too

Records can leak through more than the main page. Spend a few more minutes on these:

• Lists and search. Does user B see user A's items in any list, dropdown, or search box?
• Edit and delete. Can user B change or remove user A's record, even if they can't read it?
• Logged-out visitors. Open user A's record address in a window where nobody is logged in.
• Files and images. If users upload files, can the file link be opened by someone else?
• Admin pages. Our guide on locking down admin pages in a Base44 app covers that side.

What to do if the test fails

Don't panic, and don't ask the AI builder to "make it secure". That request is vague, and vague requests are how AI builders change things you didn't ask about. Instead:

1. Save a checkpoint or note of what currently works.
2. Tell the builder exactly one thing: "Only the user who created a record, and admins, may read, edit, or delete records in the (table name) table."
3. Run the wrong-user test again for that table.
4. Move to the next table. One table per request keeps changes small and easy to undo.

If a fix keeps failing after two tries, stop and get help rather than burning credits. Base44's own documentation describes its security settings, which is worth reading alongside this: Managing security settings.

Make it a habit

Run the test whenever you add a new kind of record or change how login works, and always before you invite real users. Keep your two test accounts and the notes file, so next time it's a five-minute check.

Frequently asked questions

Do I need to know how to code to do this? No. You need two accounts, two browser windows, and a notes file.

Does passing this test mean my app is secure? No. It checks one important thing: who can open whose records. It is not a security audit or a guarantee, and it doesn't cover payments, email settings, or everything else a launch involves.

How often should I repeat it? Each time you add a new record type or change login or permissions, and once more right before launch.

Next step

Data access is one of six areas to check before a Base44 app meets real users. Launch Readiness OS is a downloadable pack of 28 prompts, five agent role prompts, and three routines that walks you through these checks, from data access and login rules to rollback and a launch-day runbook. It is a prompt pack you apply in your own app, not a hosted scanner, a certification, or legal advice. For a lighter start, read our vibe coding security checklist.