Is your Base44 app safe?

Base44 is an AI app builder with a built-in backend. You describe the app, and it creates the pages, the data entities, user login and hosting. You do not wire up a separate database or auth provider unless you want to.

That removes a whole class of setup mistakes. It also means the important security decisions happen in Base44's settings and in the app logic it generates: whether the app is open to anyone or requires login, who can sign up, and which users can read or change which records.

• An app meant for a team or clients left open to anyone with the link, or open for anyone to sign up.
• Data entities where any signed-in user can list every record, when each user should only see their own.
• Admin screens hidden from the menu but still reachable by anyone who knows the page address. Hiding a link is not access control.
• A third party API key (OpenAI, Stripe, an email service) pasted into page code, where every visitor's browser downloads it.
• Sensitive fields such as phone numbers, addresses or internal notes returned to users who only need a name.

The admin page point matters in every builder: the check that decides who can see data has to happen where the data is served, not in which buttons the page shows.

• Who can open the app, and whether sign up is open or invite only: the app's access and visibility settings.
• Who can read and change records: the access rules on each data entity. Set records to owner only or admin only where that is what you mean.
• Third party API keys: in a backend function or a built-in integration, so the key stays on Base44's servers. The page calls the function; the function calls the API.
• Admin pages: restrict them by user role, and check that the data behind them is restricted too.

Review this app's security. List every data entity and who can read, create, update and delete its records. Change them so users only see and edit their own records, and only admins can see everything. Make admin pages require the admin role. Find any API key in page code and move that call into a backend function so the key never reaches the browser.

1. Decide who the app is for and set its visibility and sign up options to match.
2. Go through each data entity's access rules.
3. Log in as an ordinary test user and try to open an admin page and another user's record by changing the address. You should be blocked.
4. Search your pages' code for sk-, sk_live_, SG. and other key prefixes, and move any hit into a backend function. Rotate the key.
5. If you use a custom domain, check it serves over HTTPS and redirects http.
6. Scan the live URL.

The test user step above is the most important one and only you can do it, because it needs a login. Use two test accounts and make sure neither can see the other's data.

An outside scan covers what a stranger's browser can see without logging in: secret keys in the HTML and the app's own JavaScript bundles, public .env and .git files, security headers, the https redirect, cookie flags and CORS. On a hosted builder you may not control every response header, so treat header findings as information and focus first on anything in the secrets category. The scan does not log in, so it cannot test your data access rules.