What Base44 generates and where the trust boundary is
Base44 builds a hosted app from prompts. Data lives in entities (tables), users sign in through the platform's authentication, and custom server logic runs as backend functions. Confirm what your own app contains by opening the dashboard and listing the data tables, the backend functions and the visibility setting. Products change, so check the current documentation for anything that looks different from this page.
The front end runs in the visitor's browser and is public. What decides access is on the platform side: the visibility level of the app, the permission rules on each entity, and the code in each backend function. Base44's documentation describes row level security, which controls which records a user can reach, and field level security, which controls which fields. A page that hides a button is presentation. A rule that says who may read a record is access control.
Base44's security overview is direct about responsibility: it says you are responsible for your app's security settings, that Base44 provides the tools, and that you should always review your permissions and run a security scan before you publish. The assistant can set rules up for you, but the documentation still asks you to review them.
The review checklist
| Area | What to verify | How to test on your own project | Pass condition |
|---|---|---|---|
| App visibility | The visibility level (public, private or workspace) matches who should open the app. | Open the app's access settings, then open the app address in a private browser window. | An app meant for invited people asks for a login before showing anything. |
| Data permissions | Each table has rules for create, read, update and delete, and none is wider than intended. | Open each table's Permissions panel in the dashboard and read the rule for each action. | No table with user data allows all users to read or write, and no permission warning is shown. |
| Logged-out access | A visitor with no account cannot load private records. | Open the published app in a private window with the browser network tab open and look at what data requests return. | Private records never appear in responses to a signed-out visitor. |
| Cross-user access | User A cannot read or change user B's records. | Create two test accounts, add a record as A, then sign in as B and look for it in the app and in the network responses. | B never receives A's record and cannot edit or delete it. |
| Backend functions | Each function checks who is calling before it reads or writes data. | Call each function's address with curl and no login, using the example below. | Private functions refuse the call. Only deliberate public endpoints, such as webhooks, respond. |
| Service role use | Code that uses the service role does its own permission checks. | Search your function code for asServiceRole and read what runs before it. | Every service role call sits behind a check of the caller or a verified webhook signature. |
| Secrets | API keys and tokens live in the platform's secrets store, not in page code. | Search the project code for key-shaped strings and review the secrets list in the dashboard. | No third-party secret appears in any file that runs in the browser. |
| Security scan | The built-in scan ran on the final version and every finding was read. | Run the scan from the dashboard's Security area before publishing. | No unresolved finding on data permissions, exposed secrets or unauthenticated functions. |
Read the rules on each table
Base44's dashboard describes four kinds of permission rule: all users, creator only, a comparison between a field on the record and the signed-in user, and a check on a user property such as a role. The documentation describes the all users option as letting anyone perform the action, even without signing in. That option is correct for a public catalogue and wrong for orders, messages or profiles.
If you work with the developer platform, the same rules appear as an rls block on the entity. The documented values are true to allow everyone, false to block everyone, or a condition. The example below lets a user read and update only records they created, and lets only an admin delete. Compare your own entities against that shape and look for true on anything private.
{
"name": "task",
"type": "object",
"properties": {},
"rls": {
"create": true,
"read": { "created_by": "{{user.email}}" },
"update": { "created_by": "{{user.email}}" },
"delete": { "user_condition": { "role": "admin" } }
}
}Call your backend functions as a stranger
Base44's documentation says backend functions are reachable over HTTP at your app's domain under /functions/ followed by the function name. It also says that when a function is called this way there is no authenticated user, while a call made through the SDK from your front end carries the user's login automatically. So a function that assumes a user is present can behave very differently when called directly.
Run the request below against each of your own functions. Replace the domain and the function name. A private function should refuse. If it returns data or performs an action, it needs a check of the caller at the top.
export APP="https://your-app-domain.example"
curl -i -X POST "$APP/functions/yourFunctionName" \
-H "Content-Type: application/json" \
-d '{}'Judging service role code and secrets
The documentation states that asServiceRole bypasses entity access rules. It exists for webhooks and other calls with no user, and it is the single most important thing to search for. Every use should come after a check that the caller is allowed, or after verifying a signature from the service sending the webhook. Take the user's identity from the platform's authentication, never from a value in the request body.
Base44's security scan looks for exposed secrets, unauthenticated backend functions and features that spend credits without protection, such as AI, image generation and email. The documentation warns that fixing an unauthenticated function can break a page you show to signed-out visitors, a webhook or an external integration. Treat that as a reason to decide on purpose which functions are public, and write the list down.
Common mistakes with this workflow
- Leaving an app public when it was meant for a team. Base44's docs note that an app with no login cannot tell visitors apart, so per-user data cannot work.
- Accepting an all users rule on a table that holds personal data because it made an error go away.
- Assuming a function is private because no button calls it. It has a public address.
- Using the service role for convenience inside a function any signed-in user can call.
- Reading the scan summary and skipping the individual findings. The scan does not apply fixes by itself.
- Testing with one account. Cross-user leaks only show up with two.
- Treating the Admin role in the live app as editor access, or the reverse. The docs say app roles do not grant access to the editor or dashboard.
Keep it working
Re-read the permissions on any table the assistant touched, re-run the security scan and repeat the curl test after every change that adds a table or a function. Pass condition for the whole checklist: a signed-out visitor sees only intentionally public data, user B can neither see nor change user A's records, and no private function answers an anonymous call.
Frequently asked questions
Is Base44 secure?
The platform side and your app's settings are two separate questions. Base44's security overview describes platform measures such as encryption and compliance certifications, and also says you are responsible for your app's security settings. Whether your app is safe depends on its visibility, its data permissions and its backend functions, which this checklist tests.
Does the Base44 security scan make my app safe to publish?
No, it is a starting point. The documentation says the scan checks data permissions, exposed secrets, unauthenticated backend functions, credit protection, dependencies and headers, and that you must review recommendations because fixes are not applied automatically. Confirm the results yourself with the logged-out and two-account tests.
Can anyone call my Base44 backend functions?
Yes, they have a public address. Base44's documentation says functions are callable over HTTP under /functions/ on your app's domain, and that a direct call has no authenticated user. Each function therefore needs its own check of the caller unless it is a deliberate public endpoint.
What does asServiceRole do in Base44?
It runs data operations without the user's access rules. The documentation says it bypasses entity access rules and is meant for webhooks and other calls with no signed-in user. Any function that uses it must perform its own permission check first.
Should I make my Base44 app public or private?
Choose the narrowest level that fits. The docs describe public as open to anyone on the internet with no login, private as invited people only, and workspace as everyone in your workspace. Check the current plan requirements for private apps in the documentation.