Is Base44 Safe? Security Risks and the Checklist Before You Ship

You built something real on Base44 — a customer portal, an internal tool, maybe a small SaaS — and now you're asking the obvious question before you put real users on it: is Base44 safe? It's a fair worry, especially after you read that Base44 had a security incident in 2025. You're not a security engineer. You just want to know whether your app is going to leak data or let a stranger walk in the front door.

Here's the honest answer up front. Base44 the platform is not the problem. Wix, which acquired Base44, runs the infrastructure and patched the one disclosed flaw in under a day. The risks that should actually concern you are the same ones that affect every AI-built app: who can read your data, what keys you accidentally shipped, and whether the access controls your AI generated actually hold.

This post walks through the real risks when you build with Base44, the 2025 auth-bypass incident and what it teaches, and a concrete checklist to run before you ship.

⚡ TL;DR

• Base44 is safe to build on — the platform is run by Wix, and the one publicly disclosed flaw (a 2025 auth bypass found by Wiz Research) was patched in under 24 hours with no evidence of exploitation.
• The risks you own are in your app's configuration: missing access controls on your data, secret keys left in the frontend, and auth that looks fine but isn't.
• You can check most of this yourself in an afternoon — and the auth-bypass class is exactly why "it works in the demo" is not the same as "it's secure."

Is Base44 safe? The short answer

Base44 is a capable AI app builder, and using it does not make your app insecure by default. The tool generates working software fast. The question is never really "is the tool safe" — it's "is the app the tool generated safe to expose to the public internet."

That distinction matters because of how these apps are built. When you describe a feature to an AI builder, it optimizes for one thing: making the feature work in the preview. An app where any logged-in user can see any record works perfectly in a demo. The data shows up. The buttons do things. The hole only becomes visible when someone goes looking — and on the public internet, someone always does.

So the realistic risk isn't that Base44 ships broken software. It's that AI-generated apps tend to ship with insecure defaults — permissive access rules, secrets in the wrong place, missing checks — and those defaults are invisible until tested. The good news: they're also fixable, and most of them you can find yourself.

The real risks when you build with Base44

These are the gaps that actually leak data and let strangers in. None of them are unique to Base44 — they're the common failure modes of AI-built apps — but they're the ones to check on your Base44 app specifically.

Broken access control and auth bypass. This is the big one for Base44, because it's the category of the disclosed 2025 incident (more on that below). "Broken access control" means the app fails to correctly answer "is this person allowed to do this?" In practice that looks like: any logged-in user can read another user's records, or a hidden API endpoint lets someone do something the UI never offered. AI builders are especially prone to this because they wire up the happy path — the login, the dashboard, the save button — and quietly skip the part where the server re-checks permissions on every request.

Missing or permissive data access rules. If your Base44 app stores user data in a database, the most important question is whether each user can only see their own rows. The pattern that leaks is a table with row-level access controls turned off, or a rule set to "allow everyone." This is the single most common way AI-built apps leak — the database returns every record because nothing told it not to. (We go deep on this for the most common backend in Supabase security for AI-built apps; the principle is identical wherever your data lives.)

Exposed secret keys. Anything your app needs to call a paid service — an email provider, an AI model, a payments backend — usually involves a key. Some keys are public by design and meant to ship in the browser. Others are secret and must never leave your server. AI builders sometimes paste a secret key straight into frontend code "to make it work." If a secret key is in your shipped JavaScript, anyone can extract it and run up your bill. (Worth knowing which is which: exposed secrets and API keys in frontend code.)

Open storage and missing protections. If your app lets users upload files, check that one user can't read another user's uploads by guessing a URL. And like most AI-generated apps, a Base44 app may ship without standard security response headers and without protection against cross-site request forgery (CSRF — tricking a logged-in user's browser into making a request they didn't intend). These are quieter risks than a data leak, but they're real, and they're rarely added by default.

The Base44 incident: what the 2025 auth bypass teaches

Here's the incident, stated plainly, because it's the best real-world lesson in the auth-bypass class.

In July 2025, Wiz Research disclosed an authentication bypass in Base44. The flaw worked like this: every Base44 app has a public app_id. Wiz found that a public app_id, combined with two undocumented endpoints — one to register, one to verify a one-time password (OTP) — let anyone create a verified account inside any private application. That bypassed the app's single sign-on (SSO), the very control meant to keep strangers out. About 20,000 users were on the platform at the time.

Now the fair part, which matters just as much as the flaw. Wix patched it in under 24 hours. There was no evidence the bug was ever exploited. This is roughly the best a vendor response can look: found by researchers, fixed fast, no harm done. It is not a reason to distrust Base44 — if anything, the speed of the fix is reassuring.

So why dwell on it? Because the shape of the bug is the lesson. The app looked secure. SSO was configured. The login worked. But a side door — undocumented endpoints the UI never used — let someone walk around the front door entirely. That's broken access control in a sentence: the rules you see in the interface are not the rules an attacker tests. Attackers don't use your buttons; they hit your endpoints directly. The platform-level version got patched centrally. The version that lives in your app's own logic is yours to find. (For the full pattern across the ecosystem, see the vibe-coding breach timeline.)

How to check your Base44 app

You don't need to be a security engineer to catch the most common problems. Spend an afternoon on this.

1. Test as a second user. Create two accounts. Log in as user A, note a record's URL or ID. Log in as user B and try to open user A's record directly. If it loads, you have a broken-access-control problem — the same class as the 2025 incident.
2. Read your shipped JavaScript for secret keys. Open your live app, open your browser's developer tools, and look at the Network and Sources tabs. Search the bundled code for telltale prefixes like sk_, secret, or a long token next to a service name. A secret key in the frontend is an emergency; a publishable one is usually fine.
3. Probe your data the way an attacker would. Watch the network requests your app makes when it loads data. Try changing an ID in a request and replay it. If you get back data that isn't yours, your access rules aren't holding.
4. Check uploads and files. If users upload anything, grab the URL of your own upload, then try to reach another user's file by altering the path. It should be denied.

The pre-ship checklist for Base44

Run through this before you put real users — or real data — on your Base44 app.

• Access control holds. A second logged-in user cannot read, edit, or delete the first user's data by changing an ID or URL.
• No secret keys in the frontend. Your shipped JavaScript contains no sk_-style or otherwise secret keys. Publishable keys are fine; secret ones move to the server.
• Data rules restrict rows. Every table of user data enforces "users see only their own rows," not "allow everyone."
• Uploads are private. Files uploaded by one user can't be reached by another by guessing a URL.
• Endpoints are tested, not just the UI. You've replayed at least a couple of API requests with altered values and confirmed they're rejected.
• Re-checked after every change. Each time your AI adds a feature, you re-run the second-user test, because new code can open new holes.

FAQ

Is Base44 safe to use after the 2025 security incident?

Yes. The 2025 auth-bypass flaw disclosed by Wiz Research was a platform-level issue that Wix patched in under 24 hours, with no evidence it was ever exploited. The incident says more about how fast the vendor responded than about ongoing risk. Your attention is better spent on your own app's access controls and keys, which are the parts you configure.

What was the Base44 auth bypass, in plain terms?

Every Base44 app has a public ID. Researchers found that this public ID, plus two undocumented registration and OTP-verification endpoints, let anyone create a verified account inside a private app — getting around the single sign-on meant to block strangers. It's a textbook example of "broken access control," where a side door defeats the front-door login. Wix fixed it quickly.

Does Base44 handle security for me?

Partly. Wix runs and patches the underlying platform, which is why the disclosed flaw was fixed centrally and fast. But the access rules, the keys, and the logic inside your app are generated to your prompts and are yours to verify. The platform being secure does not guarantee your specific app's configuration is.

The bottom line

Base44 is safe to build on, and the one disclosed flaw was handled about as well as a vendor can handle one. The risks that remain are the ordinary ones for any AI-built app: missing access controls, secret keys in the frontend, and auth that passes a demo but not a real test. An attacker can find those gaps in minutes by hitting your endpoints directly — so the move is to find them first, and to keep checking, because your AI ships new code (and new holes) on every deploy.