Can other users see my Base44 app's data?

Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.

1. 1

   Open your published app in a private window and do not sign in. Can you see any data at all? That is your anonymous exposure, and it is the fastest thing to check.

2. 2

   Open your app's Data tab and go through every table, not the ones you remember. For each, look at Permissions. A table with no rule is the problem — Base44's API reference states it plainly: "An entity with no rls rules returns every record." That sentence appears on a page marked beta, and not on the page titled Security.

3. 3

   The one that actually proves it: make a second account on your own app. On a public app anyone can — Base44's docs say so. Sign in as user A, enter one dummy record. Sign in as user B. Can B see A's record? If yes, you have cross-tenant exposure, and no amount of hiding it in the UI fixes that.

4. 4

   Check whether a signed-in user can promote themselves. A builder reported in the Base44 Discord on 14 Sep that "an authenticated non-admin user can call User.update(self, {role: "admin"}), after which entity RLS using user.role treats them as admin", and that the built-in User entity cannot carry app-defined rules. If your permissions depend on user.role, test this before you trust them.

5. 5

   Check your backend functions while logged out. Open https://yourdomain.com/functions/<function-name> in that private window. If it returns data rather than a 401, it is callable by anyone. Base44's docs are explicit: "When calling functions via direct HTTP (like cURL or webhooks), there's no authenticated user context." There is no platform switch — the check has to be in your code.

6. 6

   Do not treat a clean security scan as proof. A Base44 Partner reported on 15 Sep that the scanner keeps returning a High finding after every recommended fix, across every one of their apps. Another builder asked on Reddit why they "have to run security scan twice". Run it, but verify by hand.

Two separate things go wrong here, and they are usually confused with each other.

1. The missing rule. When an entity has no access rule at all, the read rule imposes no restriction. Base44 documents this in exactly one sentence, on the API reference page for a beta endpoint. The page called Security does not say it. The builder-facing permissions page does not say it either — what it says is "Base44 sets up permissions automatically when it creates data tables", which is reassuring and is not always true. Nothing in the product warns you when a table is created without rules.

2. The rule that can be turned against you. If your rules test user.role, and a signed-in user can change their own role, then the rule is decorative. Same for anything stored in user.data that the client can edit — a practice_id or org_id a user can overwrite is not a tenant boundary.

Three more things worth knowing before you go looking:

• Rules are OR, not AND. From the docs: "If a person matches any one rule, they get access." Adding a stricter rule alongside a loose one does not tighten anything.
• Public apps let anyone in. If your app is set to Public, "anyone can create an account from your register page and sign in". Signed-in is not the same as authorised, and on a public app getting signed in takes about twenty seconds.
• Deleting is not erasing. Deleted records sit in the trash for 30 days and any editor can restore them. Worth knowing before you promise someone their data is gone.

This is not theoretical and it is not rare. Two builders raised tenant-isolation failures in the Base44 Discord in the same week — one of them reporting they had "reproduced a failure of Base44's documented multi-tenant RLS pattern using entirely synthetic data".

Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.

Audit this Base44 project for data exposure. I want to know whether people can
read or change records they should not.

READ ONLY. Do not edit, create or delete any file, entity, schema or record. Do
not change any access rule. Do not run a security scan. Do not deploy. If
something should change, describe it — do not do it.

EVIDENCE RULE — this governs everything below.
Every finding must carry one of:
  [SCHEMA]      the entity name and the exact rule block, quoted
  [CODE]        a file path and line number
  [LIVE]        a URL you fetched, with the HTTP status code you received
  [UNVERIFIED]  you could not check it from here
You may not report PASS, SECURE or "looks fine" for anything you have not
evidenced. If you cannot verify it, the answer is UNVERIFIED. Never infer that
something is protected because the code looks like it should be.

DO NOT print the contents of any record. Field names and counts only. If you
…

Using the audit you just produced, apply the fixes. The audit was read-only;
this turn is the only one that writes.

BEFORE YOU CHANGE ANYTHING, STOP AND ASK ME ABOUT PUBLIC READS.
Some entities are meant to be readable by everyone — published articles, price
lists, public listings, league tables. Clamping those breaks the live app. List
every entity you are about to restrict, say what you believe it is for, and wait
for me to confirm before you touch a read rule on any of them.

Then, in this order:
  P0  entities holding personal data with no rule at all
  P0  backend functions with no authentication check
  P0  any rule a signed-in user can defeat by editing their own role or user.data
  P1  entities with rules that are looser than they need to be
  P2  tidying

For a user-owned entity the shape is:
  read:   { "created_by": "{{user.email}}" }
…

Prove the fixes worked. Do not trust the previous turn's report.

PART 1 — THE OUTSIDE TEST
For each entity that was unruled before, fetch it with no authentication:
  https://<the app's domain>/api/apps/<app_id>/entities/<EntityName>
Report the HTTP status code and the NUMBER of records returned. Never print the
records. A 200 with records means it is still readable by anyone.

Do the same for every backend function that had no auth check:
  https://<the app's domain>/functions/<function-name>
A 401 is the result you want.

PART 2 — THE SECOND-USER TEST
This is the one that catches real-world leaks, and you cannot do it — I have to.
Write me the exact steps for my own app: which two accounts to create, what
record to enter as the first user, what to look at as the second, and what I
should see if it is correct. Be specific to the entities in this project, not
generic.
…

• Base44 — list entity records (the one page that states the default)"An entity with no rls rules returns every record." It is not on the page titled Security.
• Base44 — entity security referenceRule syntax and a worked example. Does not state the no-rule default.
• Base44 — managing security settingsThe builder-facing page. Rules are OR, not AND — "If a person matches any one rule, they get access."
• Base44 — backend functions overview"When calling functions via direct HTTP (like cURL or webhooks), there's no authenticated user context."
• ICO — personal data breaches: a guideUK: 72 hours from becoming aware, if the breach is likely to risk people's rights and freedoms.
• ICO — breach self-assessment toolAbout five minutes. Tells you whether it is reportable.