# Base44 app security: what a stranger can read

Checked on 1 November 2026

In a Base44 app, a stranger (anyone who is not signed in) can read every record in any entity, Base44’s name for a data table, whose Read permission is set to All Users, and all the code your app sends to the browser.

To close this, give every entity that holds people’s data a Creator Only or admin-only rule for Read, Update and Delete on its Permissions page, run Base44’s free security scan, and check your live app again while signed out.

LidTight’s free check helps with that last step: it finds the entity names in your public code and counts the records a stranger can read, reading at most one per entity to learn its fields.

## How a Base44 app keeps its data

Base44 keeps your app’s data in entities. The [developer docs](https://docs.base44.com/developers/backend/resources/entities/overview) describe each entity as a schema (a list of fields) for one collection of records in Base44’s database; the app editor calls it a data table. Your pages read it with calls such as base44.entities.Task.list(), as the [SDK docs](https://docs.base44.com/developers/references/sdk/getting-started/work-with-data) show.

Each entity has permission rules for Create, Read, Update and Delete. [Base44 sets them automatically](https://docs.base44.com/Setting-up-your-app/Managing-security-settings) while the AI builds your app, and you can change them at any time. A person who matches any one rule gets access.

| Rule | Who it lets in | Fits |
| --- | --- | --- |
| All Users | Anyone, even without signing in | Public data, such as a product catalog |
| Creator Only | Only the person who created the record | Orders, messages, form submissions |
| Entity-User Field Comparison | A signed-in person whose account matches a field on the record | Tasks or tickets given to one person |
| User Property Check | Signed-in people with a set property, such as the Admin role | Actions only your team may take |

A field-level rule can also hide one field, such as an email, while the rest of the record stays readable. And a backend function (code that runs on Base44’s servers, not in the browser) can use the service role, which [skips every entity rule](https://docs.base44.com/developers/backend/resources/entities/security), so that function must check who calls it.

## App visibility and sign-in are a separate lock

[App visibility](https://docs.base44.com/Setting-up-your-app/Managing-access) decides who can open your app. Public is anyone on the internet, with no sign-in. Private is only invited people, on paid plans only. Workspace is everyone in your Base44 workspace. Base44 sets apps that look like public sites, such as landing pages, to Public without login by itself.

Visibility does not replace data rules. Base44’s docs treat visibility as who can get in, and data permissions as who can see or change each table, so set both. On a Public app, anyone can create an account on your register page. Sign-up with email and password always asks for a [6-digit email code](https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration), but a confirmed email says nothing about trust. Your rules must check whose record it is, not only that someone signed in.

This lock has failed before. In July 2025, [Wiz reported](https://www.wiz.io/blog/critical-vulnerability-base44) that anyone who knew a Private app’s app id could register a verified account on it. Base44, part of Wix, fixed it for every app in under 24 hours, and Wix found no evidence of abuse. A Creator Only rule keeps other people’s records safe even when someone gets past the sign-in.

## What a stranger sees in your app’s browser code

Every visitor’s browser downloads the code that draws your pages, and anyone can read it with the browser’s developer tools. In a Base44 app, it shows:

- **Your app id.** [Wiz found it](https://www.wiz.io/blog/critical-vulnerability-base44) in each app’s web address and manifest file path. It is not a secret.
- **Your entity names**, in calls such as base44.entities.Order.list(). A name alone exposes nothing: the entity’s Read rule decides what a request returns.
- **Any key the AI put in a page.** Anyone can copy an API key (a password your app uses to call a paid service) from browser code. Base44’s docs say keys belong in [secrets management](https://docs.base44.com/Setting-up-your-app/security-overview), a vault only your backend can read.
- **Calls to paid features.** Base44’s scan flags AI, image or email features that someone can [reach from outside your app](https://docs.base44.com/Setting-up-your-app/running-a-security-scan), including AI calls from your pages, and use to spend your credits. See [someone is running up your AI bill](https://lidtight.com/guides/ai-bill-abuse).
- **Backend function addresses.** Each one has its own web address. If your app does not require login, [anyone can call them](https://docs.base44.com/Setting-up-your-app/running-a-security-scan).

When a rule denies a list or filter read, Base44 returns [an empty list, not an error](https://docs.base44.com/developers/backend/resources/entities/security). So if you see no records while signed out, compare with the record count in your dashboard: an empty entity and a protected one look the same.

## How to check your own Base44 app

1. Run Base44’s security scan: click **Dashboard**, then **Security**, then **Run Security Scan**. It is [on every plan, the free plan too](https://docs.base44.com/Setting-up-your-app/running-a-security-scan); its code analysis needs the Builder plan or above. It checks permissions, private fields on public tables, exposed keys, backend functions, credit use and libraries with known flaws. The publish panel shows the result, but it only warns: it does not stop you from publishing.
2. Read each entity’s rules. In **Dashboard**, under **Data**, open each table and click **Permissions**. Look for All Users on Read, Update or Delete, and for a “Permission risks detected” banner.
3. Test as your users. Click **Test Permissions in preview** and switch between people. Use sample users, because changes you make while testing are saved to their data.
4. Check from outside. Open your live app in a private browser window, signed out, and visit every page. Then run the [free check](https://lidtight.com/#check-now) on your live link.

The free check reads only what any browser can see. On a Base44 app, it takes the app id from the page and the entity names from the code. Then it asks your app, as a stranger, how many records each entity returns. If there are records, it reads one to learn the field names and to test whether the values look like names, emails or phone numbers. It sends only read requests and keeps no values.

An open entity with personal fields is rated critical, and an AI step can lower that rating when the entity looks public by design. An open entity named like Customer or Order is rated high even with no personal fields. Other open entities with nothing personal share one medium warning. The page shows what is open and how serious; the entity’s name, the proof and the fix are in the report.

For an example: on 1 November 2026, LidTight’s check on Tidybook, our demo app built with Lovable (not Base44), reported a critical finding: “Anyone can read your reviews table: 12 rows, with first_name, email, phone”. On a Base44 app, the same kind of finding names an entity.

The check sees only the entities your code names. It does not test signed-in users on Base44 yet, so use Test Permissions in preview to find out [whether one customer can see another’s data](https://lidtight.com/guides/one-customer-sees-another). It also skips the sign-up check on Base44, because it cannot read Base44’s sign-up settings from outside.

> This page shows no result of our check on a Base44 app. It describes what the check does, from the check’s own code.

## What to fix, and how to ask Base44’s AI

Base44’s AI chat sets permissions from plain requests, and it [asks for your approval](https://docs.base44.com/Setting-up-your-app/Managing-security-settings) before it changes rules you already have. Describe how your app should work, then read the rules it proposes.

| What you find | The fix in Base44 |
| --- | --- |
| People’s data with All Users on Read | Creator Only on Read, Update and Delete, plus a User Property Check for admins |
| A public entity, such as reviews, with emails or phone numbers | A field-level rule that shows those fields only to the creator and admins |
| Rules that rely on a profile field users can edit, such as company | Lock the field so only your app’s editors can change it |
| A key in your page code | Move it to secrets and call the service from a backend function |
| AI or email called from the browser | Move the call into a backend function |
| A backend function anyone can run | Require a signed-in user, or check the sender’s signature for a webhook |

Prompts you can paste into the AI chat:

```
Review the permissions on every entity. For each entity with data about people, such as names, emails, phone numbers, orders or messages, set Read, Update and Delete to Creator Only, and let the Admin role read, update and delete all records. Show me the rules before you change anything.
```

```
On the Review entity, hide the email and phone fields from everyone except the record’s creator and admins. Keep the other fields public, and update any page that shows these fields to everyone.
```

Permission changes [take effect at once](https://docs.base44.com/Setting-up-your-app/Managing-security-settings). If your app does not require login, [a permissions fix can break](https://docs.base44.com/Setting-up-your-app/running-a-security-scan) a page where visitors look up something they sent, such as a booking; the AI chat then offers **Fix the visitor lookup page**. After each fix, scan again, test in preview and check from outside.

Under **Browser Security** in your app settings, you choose which websites may show your app in a frame. Base44’s docs say the Content-Security-Policy and Strict-Transport-Security headers (instructions sent with each page) [cannot be set per app](https://docs.base44.com/Setting-up-your-app/security-overview), and Base44 manages CORS (which other websites may read your app’s answers in a visitor’s browser) itself. If a header checker lists those, our free check included, that part is Base44’s, not yours. See [security headers and CORS](https://lidtight.com/guides/security-headers-cors).

Before launch, go through [the launch checklist](https://lidtight.com/guides/launch-security-checklist), and read [is your AI builder’s own scan enough](https://lidtight.com/guides/is-builder-scan-enough).

## Sources

1. [Base44 docs: Base44 security, an overview](https://docs.base44.com/Setting-up-your-app/security-overview)
2. [Base44 docs: Managing data permissions](https://docs.base44.com/Setting-up-your-app/Managing-security-settings)
3. [Base44 docs: Choosing who can access your app](https://docs.base44.com/Setting-up-your-app/Managing-access)
4. [Base44 docs: Managing login and registration](https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration)
5. [Base44 docs: Running a security scan](https://docs.base44.com/Setting-up-your-app/running-a-security-scan)
6. [Base44 developer docs: Entities overview](https://docs.base44.com/developers/backend/resources/entities/overview)
7. [Base44 developer docs: Entity security rules](https://docs.base44.com/developers/backend/resources/entities/security)
8. [Base44 SDK docs: Work with data](https://docs.base44.com/developers/references/sdk/getting-started/work-with-data)
9. [Wiz Research: critical vulnerability in Base44 (29 July 2025)](https://www.wiz.io/blog/critical-vulnerability-base44)