Is my Base44 app secure? A pre-launch security checklist for Base44 apps

Last updated October 26, 2026 · By Ember, SniffPup

Short answer: not automatically, but Base44 gives you more built-in security tooling than most AI app builders: a security scan on every plan, permission recommendations on each data table and a way to test your app as different people. Base44's own docs are clear that you are responsible for your app's security settings, so use those tools before you publish, then check what your live site shows a stranger.

SniffPup looks at your published site the way a stranger would: secret keys in your HTML and same-origin JavaScript (masked in the report), public /.env and /.git files, a downloadable source map, missing security headers, cookie flags and HTTPS. It gives your site a 0–100 score. A 100 means no issues were found in our checks; it is never proof of security. Every critical issue comes with its full fix and a fix prompt you can paste into Base44's AI chat, free (with no critical, one other fix is free). It's passive: no logins, no attack traffic, and it never uses a secret key it finds. It doesn't test your Base44 data permissions or call your backend functions; Base44's scan and your own tests below cover those. Signed in, your reports stay in the My scans tab so you can re-check after each publish.

1. Run Base44's security scan first

Base44's scan is genuinely thorough, and it's on every plan, including free (Base44 security scan docs). Per the docs, it looks for:

• Data permission issues: tables with missing rules, or people with more access than they should have.
• User fields users can change: custom profile fields (such as a company field) that your rules rely on but users can edit on their own profile.
• Exposed secrets: API keys, passwords or tokens somewhere visitors could reach them.
• Unauthenticated backend functions: functions a stranger could call without signing in.
• Credit protection: AI, image generation or email features that can be reached from outside your app and spend your integration credits.
• App dependencies with known vulnerabilities, and two browser headers (iframe embedding and Permissions-Policy).
• Code vulnerabilities such as missing access checks or unsafe input handling, on the Builder plan and above.

Two habits from Base44's own docs: review what each fix changes before you apply it (each fix creates a checkpoint you can revert to), and run the scan again after you change your app. The publish panel shows your security status, but it warns rather than blocks, so a red status can still go live.

2. Set data permissions on every table

Base44 sets up permissions as it builds your tables, and you can change them in plain language through the AI chat or on each table's Permissions page (Base44 data permissions docs). The rule types to know:

• All Users: anyone can do this, even without signing in. Fine for Read on a product catalog or blog. A leak on orders, messages or anything personal.
• Creator Only: people can only reach records they created. The usual choice for Read, Update and Delete on personal data.
• Entity-User Field Comparison: a field on the record must match the signed-in person, for example assigned_to = their email.
• User Property Check: only people with a given account property, such as the Admin role.

A person who matches any one rule gets access, so an extra rule widens access rather than narrowing it. If a table shows a Permission risks detected banner, open More details to read the recommended rules before you apply them. For single sensitive fields, like a participant's email, Base44 also supports field-level rules (entity security docs).

Watch the fields your rules trust. Users can change the custom fields on their own profile. If a rule decides access from one of those fields (a company, team or level), a user could change it to someone else's value. Base44's scan now flags these under User fields users can change; lock them so only your app's editors can set them.

Public forms: for a contact or sign-up form, Base44's own example is All Users on Create and admin-only Read, Update and Delete. Create stays open to direct API calls, not just your form, so a CAPTCHA on the page doesn't stop scripted submissions. If spam or abuse matters, send the form through a backend function that checks the input and verifies the caller before it writes.

Paste this into Base44's AI chat:

For every data table in this app, list the current Create, Read, Update and Delete rules in plain language and say whether a signed-out visitor can use each one. Change any table that holds personal data so people can only read, update and delete their own records, and only admins can see everyone's. List what you changed.

3. Pick who can open your app

App visibility is set under Dashboard → Overview → App Visibility (Base44 access docs). Public means anyone on the internet, with no sign-in required; Workspace means members of your Base44 workspace, signed in; Private means invited people only, signed in (paid plans). Base44 may set landing-page-style apps to Public automatically, so check this before you share an internal tool. Visibility controls who can open the app; data permissions still decide what each person can see inside it.

4. Keep API keys in Secrets and backend functions

• Anything in your app's pages runs in the visitor's browser, so a key pasted into page code is readable by anyone. Base44 recommends handling every call to an outside service in a backend function (backend functions docs).
• Store keys on the Secrets page (Dashboard → Secrets → Add Secret), and read them in the function with secrets.get() inside the handler. Base44 says secret values stay on the server and never reach the browser (Base44 secrets docs).
• After you add or change a secret, publish again: per Base44's docs, the live app keeps the values it had when you last published.
• Anyone who can edit your app can see the first characters of saved secrets and change them, so keep the editor list short.

If a secret key has ever been in page code, a public repo or the browser, rotate it at the provider. See what to do after leaking an API key. If you sync your app to a public GitHub repo, the free repo scan in the Sniff & Fix tab checks it for committed keys and .env files.

5. Lock down backend functions anyone can call

Each backend function gets its own web address, so it can be called directly, not only from your app. Two facts from Base44's docs matter here:

• If your app doesn't require login, anyone can call your functions. The scan lists them, with ones that write data or use AI marked High. To secure one, require login for the app, or verify the caller inside the function: a provider signature for a webhook, or a shared secret for anything else.
• asServiceRole skips every data rule. A function that reads or writes with it bypasses row-level and field-level security, so it must check who is asking before it returns data or makes a change.

The same goes for AI and email features: if the scan shows Prevent unauthorized credit usage, fix it before you share the app, so strangers can't spend your credits.

6. Test as a stranger and as a second user

1. On each table's Permissions page, click Test Permissions in preview and act as different people. Changes you make there are saved to that person's data, so use sample accounts.
2. Open your published app in a private window, signed out. You should see only what you meant to make public, never other people's records.
3. Sign in as a second test account and try to open the first account's records, for example by changing an ID in the URL. It should fail or show nothing.

7. Check what your live site exposes

• Public /.env or /.git/config files (you should get a 404 or your app's normal page, never file contents)
• Secret keys in the JavaScript your pages load (anything other than values meant to be public)
• Missing security headers (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
• Cookies without Secure, HttpOnly or SameSite flags

Base44 lets you turn on iframe blocking and Permissions-Policy under Dashboard → Settings → Browser Security. SniffPup's header check covers a wider set, so check what Base44 lets you change before you chase each one. A free SniffPup scan checks all of these at once; for headers on their own, try the security headers checker.

About the 2025 Base44 sign-up bug

In July 2025, Wiz Research reported that two undocumented sign-up and verification endpoints let anyone register for a private Base44 app using only its app_id, which is visible in the app's URL and manifest. Per Wiz, Wix fixed it within 24 hours of the July 9, 2025 disclosure, found no evidence of abuse, and customers didn't need to take any action. It was a platform bug, not something builders configured, and it's a good reminder that your app_id is not a secret: your data rules have to hold up even when a stranger knows it.

Where SniffPup fits

Base44's scan sees inside your app: your tables, rules, functions and code. SniffPup sees what your live site actually serves to the public, which is what a stranger sees first. See exactly what the scanner does.

What Base44's scan sees vs. what an outside scan sees

The two work best together: fix what Base44 flags, publish, then check what the public sees.

FAQ

A clean report is not a guarantee of security, and a 100 score means no issues were found in our checks, not proof of security. Only scan sites you own.

Run a free scan →