Base44 handles a lot for you. It gives your app a database, logins, and hosting, so you can go from idea to a working base44.app link without touching a server. That makes it one of the easiest ways to launch something real.
It doesn't make security automatic, though. Base44's own docs say it plainly: you are responsible for your app's security, and you should review your settings and run a security scan to make sure everything is set up the way you meant. This checklist walks through what that means in practice.
1. Run Base44's security scan
Base44 has a built-in scan, and it's available on every plan, including free.
- Click Dashboard in your app editor.
- Click Security.
- Click Run Security Scan.
The scan checks data permissions, exposed secrets, and vulnerable code, and gives each finding a recommended fix you can apply in one click. If an area shows Not checked, run it again.
Two things worth knowing from Base44's docs. First, when you publish, the publish panel shows your app's security status, but it warns you rather than stopping you. A green publish button doesn't mean the scan is clean. Second, a permissions fix can sometimes break a page where visitors look something up without logging in, like a booking. Base44 offers a ready-made follow-up request in the AI chat for that case. Test those pages after applying fixes.
2. Set data permissions on every table
This is the most important item. Each table in your Base44 app has its own permissions that decide who can create, read, update, and delete its records. If a table is set so "all users" can read it, anyone using your app can read every record in it.
To check them:
- Open Dashboard → Data and select a table.
- Click Permissions at the top.
- For each action, ask: who should really be able to do this?
For most private data, like orders, messages, or profiles, the right answer is "only the person who created the record," plus admins if you need them. Base44 can match a record to the signed-in user, for example by the created_by field.
If a table has a permission risk, Base44 shows a warning icon on its card and a Permission risks detected banner on the Data page, with a Fix button that applies the recommended rules.
Prompt for the Base44 chat:
Review the permissions on every data table. For private data, only the record's creator and admins should be able to read, update, or delete it. Tell me which tables are readable by all users and whether that's intended, before changing anything public.
3. Watch out for profile fields used in rules
This one is subtle, and Base44's scan calls it out specifically. Users can edit the custom fields on their own profile. If one of your access rules relies on one of those fields, such as a "company" field that decides which records someone sees, a user could change their own company to someone else's and get their access.
The scan lists these under User fields users can change. The fix locks the field so only your app's editors can change it. After applying it, test any signup or onboarding steps that set the field.
4. Test permissions as another user
Rules are easy to misread. Base44 lets you check them directly: from a table's More actions menu, or after saving a permissions change, click Test Permissions in preview. Your preview opens as a chosen person, so you can see exactly what each of them can reach.
Then do it for real on the published app:
- Open your live app in a private browser window.
- Sign up as a second person.
- Try to find the first person's records, including by changing an ID in the address bar.
5. Keep keys in Secrets, not in the chat or the code
If your app talks to outside services like Stripe, OpenAI, or an email provider, those keys belong in Base44's Secrets page (Dashboard → Secrets), used by backend functions. Base44's docs say backend functions run on the server, so the key never reaches the browser.
The Secrets page shows up once your app has backend functions, which need a Builder plan or higher. If you're on a lower plan, be careful about any integration that asks you to paste a secret key somewhere it would end up in your app's frontend.
If a secret key was ever in your app's frontend code, make a new one in that service's dashboard and delete the old one. More on that in How to hide API keys in a React app.
6. The launch-day basics
When I ran a free check on 34 apps shared on X in one week, 11 of them on base44.app addresses, every app was missing basic browser safety settings (security headers), and most had no sitemap. None of that is a disaster on its own. It's worth a few minutes:
- Link preview. Text your link to yourself. Does it show a real title, description, and image?
- Findable. Check whether your app has a sitemap and a page title Google can use.
- A way to reach you. A contact email or form, so early users tell you about bugs.
The short version
- Run Base44's security scan from Dashboard → Security, and fix critical findings.
- Set permissions on every table so private records are creator-only.
- Lock any profile field your rules depend on.
- Test as a second user, in preview and on the live app.
- Keep keys in Secrets, used by backend functions.
Base44's scan looks at your app from the inside, and you should use it first. The free Throttle Bird scan is a second look from the outside: it reads your live page and its JavaScript the way a visitor's browser does, and checks for exposed secret keys, security headers, HTTPS, link previews, and whether Google can find you. It doesn't test Base44's data permissions directly, so steps 2 to 4 above are still yours to do.
Sources: Base44: Running a security scan, Base44: Managing your app data, Base44: Managing data permissions, Base44: Using integrations.