Base44 Security: RLS, Roles and Mistakes to Avoid

Base44 is secure enough for real business apps if you set up its security rules correctly. The platform handles login, HTTPS and server-side permission checks. Your job is to set row-level and field-level security on every entity so each user can only see and change what they should. Most Base44 security problems we see come from missing or loose rules, not from the platform itself.

We are a Base44 Legend Partner and review Base44 apps for security as part of client work. We test rules against the live database as an anonymous visitor through the API, not only through the app's screens. This guide covers what to set, what to avoid and how to test.

Is Base44 secure?

The platform is built with the right tools: authentication with email and password, social logins and custom SSO, server-enforced data rules, and automatic HTTPS on custom domains, per the Base44 backend docs. Like any platform, it has had issues. In July 2025, the research firm Wiz found a login bypass, and Base44 fixed it within a day. More on that below.

The bigger risk is the app you build. AI-written code in general often has security gaps.

What is row-level security in Base44?

Row-level security (RLS) decides which records each user can create, read, update or delete. You set a rule for each of those four actions on each entity. A rule can allow everyone, block everyone, or allow only records that match a condition, as the Base44 security docs describe.

Conditions can check:

• The user's role, for example only admins.
• A match between the user and the record, for example the record's creator email equals the logged-in user's email.
• Fields on the record itself, for example only records marked as published.
• Combinations, using operators for "or", "and", "not" and "in a list".

A good default for most business data is: users can read and edit only their own records, and admins can do everything.

What happens when Base44 denies access?

Base44 is careful not to leak information when it blocks a request.

In practice, a blocked list or filter returns an empty result, a blocked lookup of a single record returns not found, and a blocked create or update returns a forbidden error. That is useful to know when testing: an empty list is what a working rule looks like.

What is field-level security in Base44?

Field-level security (FLS) hides or locks individual fields inside a record. The Base44 docs use a salary field as the example: everyone on a team can see a staff record, but only admins can see the salary. Use FLS for internal notes, pricing, cost data, personal details and anything a user should not be able to change, like their own role.

What is the service role and why is it risky?

Inside backend functions, Base44 lets code act with full admin rights through the service role. That is useful for jobs like nightly reports or processing a payment, but it removes every protection you set.

If a backend function uses the service role, check who can call it and what input it accepts. A function that takes a record ID from the user and returns that record with admin rights can expose your whole database.

What are the most common Base44 security mistakes?

1. 1Leaving entities open. An entity with no read rule, or a rule that allows everyone, can be read by anyone who finds the API.
2. 2Relying on hidden screens. Hiding the admin page from regular users does not stop them from requesting admin data directly.
3. 3Letting users edit their own role. If the role field is writable, any user can make themselves an admin. Lock it with FLS.
4. 4Matching on the wrong field. A rule that matches a field the user can edit, such as an owner email they can change, can be bypassed.
5. 5Overusing the service role. Every backend function with admin rights is a door that skips your rules.
6. 6Forgetting logged-out visitors. Rules that reference the user block anonymous callers, but rules set to allow everyone do not.
7. 7Putting API keys in the front end. Keys belong in secrets used by backend functions, never in browser code.

How do you test the security of a Base44 app?

Test before launch and again after any big change. Here is the process we follow:

1. 1List every entity and write down who should be able to create, read, update and delete each one.
2. 2Compare that list with the actual RLS and FLS rules in the app. Fix any gaps.
3. 3Log out and try to load data. As an anonymous visitor, private entities should return nothing.
4. 4Create two ordinary user accounts. As user A, try to open, edit and delete user B's records by changing IDs in the address bar.
5. 5Try to change protected fields, such as your own role, and confirm the change is refused.
6. 6Review every backend function that uses the service role and check what it trusts from the caller.

What was the 2025 Base44 vulnerability?

In July 2025, Wiz found that undocumented registration and verification endpoints let someone create an account on a private Base44 app using only its public app ID. That could bypass login, including on apps protected by SSO.

Wiz reported it on July 9, Base44 fixed it on July 10, and Wiz published its findings on July 29, 2025. Coverage in The Hacker News and the Wiz write-up both note the quick fix.

The lesson for builders: platform bugs happen on every platform, and good RLS limits the damage. An attacker who got past login on an app with strict rules would still only see what an ordinary new user could see.

Should you get a Base44 security review?

If your app stores customer data, payments, health or financial information, or anything you would not want public, yes. A review is quick compared with the cost of a leak. We are a Base44 Legend Partner and Base44 Ambassador, and security checks are part of every app we ship. See our Base44 developers page or app development services.

Building your first app? Our Base44 tutorial sets up RLS from the start, and our Base44 integrations guide covers keeping API keys safe.

Roenic Natarelli

Founder, Virtual Horizons

Roenic runs Virtual Horizons and is a Base44 Legend Partner, Ambassador and Community Pillar, Base44 Shark Tank winner and multiple-time Vibe Sprint winner. The studio builds web and mobile apps, AI voice agents and automations, with more than 10 apps live on the App Store and Google Play. More about us