Is Base44 safe? Security checks before you launch
Base44 itself is patched: Wiz and Imperva disclosed serious platform flaws in 2025 and both were fixed. It now includes a security scan on every plan. That scan covers a lot, but the logic of your own app is still yours to test, starting with whether one user can open another user's records by changing an id.
Base44 had two serious, publicly disclosed platform flaws in 2025, both found by outside researchers and both fixed. Since then it has added a built-in security scan that every plan can run. So the platform question has a reasonable answer, and the useful question is the one about your own app. This page covers what went wrong, what Base44 checks for you today, and the handful of things no platform scan can decide for you.
What went wrong in 2025?
July 2025, Wiz. Wiz reported that two endpoints in Base44's shared SDK, user registration and one-time password verification, accepted requests without authentication. Both trusted an app_id that was visible in every app's URL, so anyone holding that id could register and verify an account inside a private app, including apps that sat behind single sign-on. Wiz disclosed it on 9 July, Wix fixed it within 24 hours, and Wiz confirmed the fix on 10 July.
August 2025, Imperva. Imperva published a set of flaws that ranged from an open redirect that leaked access tokens to stored cross-site scripting, sensitive data leakage, and premium features enforced only in the browser. Imperva described how the XSS and the weak premium checks combined into a path to account takeover, and listed the fixes Base44 deployed.
Neither bug was in any customer's code. They lived in the platform that every Base44 app shares, which is why one flaw covered all of them at once. Both are closed, and you cannot reach them today.
What do those incidents still teach?
Shared infrastructure means shared blast radius. On a hosted builder your authentication is one implementation used by every customer, so a defect in it is not your bug and is still your problem. For most people that is still the right trade, because the auth you would write yourself has bugs too. It is worth making the trade knowingly.
Public identifiers are inputs, not secrets. The app_id was doing security work nobody had decided it should do. If your own app treats an id in a URL, a tenant slug or a project key as something attackers cannot see, you have built the same class of problem at a smaller scale.
Premium checks in the browser are suggestions. Imperva's finding about client-side premium enforcement is the platform-level version of a bug that turns up in generated apps all the time: the button is hidden, but the request behind it still works.
What does Base44's own security scan check?
According to Base44's documentation, the scan is available on every plan, including free, and reports seven kinds of issue:
- Data permission issues, where a data table has no permission rules or gives people more access than they should have
- Exposed secrets, such as API keys, passwords or tokens that visitors could reach
- Unauthenticated backend functions that hand out data without checking who is asking
- Credit protection, for AI, image or email features reachable from outside the app
- App dependencies with known vulnerabilities
- Code vulnerabilities, which need the Builder plan or higher
- Security header recommendations, weighted by whether the app has login or payments
The scan warns you before you publish but does not block publishing, and it can send a finding to the AI chat to apply a fix. Run it before every launch. It is free and it knows the platform better than any outside tool.
What is still mine to check?
The parts that depend on what your app is supposed to do. A scanner can see that a rule exists; it cannot know whether user A should ever see user B's invoice.
- Cross-account reads. Make a second account, then load a record belonging to the first by changing the id in the address bar or in a request. This flaw is invisible while you only ever test as yourself.
- Server-side plan checks. From a free account, call a premium feature with the network tab open. If it answers, the paywall is a hidden button and nothing more.
- Keys in the browser. On the deployed app, search every loaded file in developer tools for
sk-,secretandtoken. Anything that looks live should be treated as live. - What you connected. Every integration you wired up carries its own credential and scope, and the scope is usually wider than the feature needs.
- What the app collects. A form built in an afternoon collects whatever fields the model suggested. If that includes phone numbers or addresses, you have obligations a security scan will not cover.
Can an outside code scanner read a Base44 app?
Only if the code is in a repository. Base44's GitHub integration keeps an app in two-way sync with a repository, and it needs the Builder plan or higher. Once the code is in GitHub, any repository scanner, including Sentrint, can read the frontend, entities and backend functions that sync there.
Be clear about the limits. A repository scan reads code; it cannot see settings that live only inside Base44, and it would not have caught either 2025 flaw, because those were in the platform rather than in anyone's repository. It also does not log in to your app, so it misses anything that only shows up at runtime. For a Base44 app, an outside scan is a second opinion on the code you own, next to Base44's scan and your own two-account test, not a replacement for either.
What should I do this week?
Run Base44's security scan and fix what it reports. Then do the two-account test above, which takes ten minutes and finds the flaw that platform scanners are least able to judge.
If your app is synced to GitHub, a repository scan adds a check of the code itself in plain English, with a fix prompt you can paste back into Base44's chat. You can read a full sample report to see what that looks like, and the first scan is free with no card.