Base44 Security: What the Wiz Finding Means for You

Base44 security became a public topic in July 2025, when Wiz researchers found that an attacker could register on Base44 apps meant to be private using only the app’s ID. The platform, owned by Wix, fixed it within a day. The flaw was in the platform, not in any one owner’s app, and it is closed.

That does not mean your app is automatically safe. The platform secures its infrastructure and accounts. You are responsible for who can read which data in your app. I am a Brazilian engineer who works with AI-built apps, and this is how I would read the finding and what I would check.

What did Wiz researchers find in Base44 in July 2025?

Wiz researchers found an authentication gap in Base44. Apps that were meant to be private could be reached by someone who knew only the app’s ID. With that ID, an attacker could register a new account on the app, even though the owner had set it up as a closed, private application.

Why an app ID mattered

An app ID is usually not treated as a secret in most systems. Identifiers like it can show up in URLs, network requests or front-end code. A design where knowing the ID is enough to get past registration controls turns a semi-public identifier into a door. That is why researchers took it seriously.

What it did not mean

It does not mean Base44 apps are inherently insecure, and it does not mean every app was breached. I am only relying on what was publicly reported: the flaw existed, and it was fixed. I would not claim more than that, and I would be wary of anyone who does.

How quickly was it fixed?

Per the public reporting, the issue was fixed within a day. For a platform-level vulnerability, that is a fast response. Speed matters because every hour a flaw stays open, more people could find it.

A quick fix does not tell you whether anyone used the flaw before it was closed. The public reporting does not say whether anyone used the flaw before it was closed, so I would not assume either way. That is a reason to look at your own user list, which I cover below.

Is Base44 safe to use now?

The specific Wiz issue is fixed, so that hole is closed. Whether your app is safe depends on how it is configured and what it does.

I would treat Base44, Lovable, Bolt and similar tools the same way: they are good at getting a working first draft. AI-generated code should be reviewed like any first draft. The platform being sound does not make the logic inside your app sound.

A prototype with test data and no payments carries low risk. An app with real customer data, logins and Stripe is different. The more that is at stake, the more a short review is worth.

Which parts of security does Base44 handle, and which are yours?

Security is a shared responsibility. The table shows the split I use when I explain it to founders.

The Wiz finding sat in the first two rows, so the platform had to fix it. In my experience, the problems that tend to matter most in AI-built apps sit in the lower rows, where the owner is responsible.

What should Base44 app owners check today?

You do not need a full audit to catch most of the risk. Four focused checks cover most of it before real users arrive.

1. Data access rules

For each type of data, ask: can a logged-in user read or edit another user’s records? Test it. Create two accounts and try to open the second account’s data from the first. In Lovable apps, weak Supabase row-level security has been a repeated pattern, and the same question applies on any builder.

2. Exposed keys

Open your app in a browser, look at the network requests and the page source, and search for anything that looks like a secret key. Public keys are fine. Secret keys for payments, email or AI services must live on a server, never in the browser. If one leaked, rotate it.

3. Payment confirmation

Do not trust the browser to say a payment succeeded. Your app should confirm payment through Stripe events verified on the server. Check what happens if an event arrives twice, arrives late, or never arrives. Generic scanners miss this because it is business logic, not a known vulnerability pattern.

4. Backups

Find out where your data lives and whether you can restore it. A backup you never restored is a guess. Export a copy of the data you could not afford to lose.

Also review your user list

Because of the Wiz finding, look through your registered users in a private app. Remove accounts you do not recognize and check whether any of them touched data. This takes minutes and tells you something real.

When should you move off Base44?

Staying is sometimes the better call, and I do not push people to leave by default. Moving costs time and creates its own risks.

Reasons to stay

• You are validating an idea with a small number of users and no sensitive data.
• The app is simple and you can pass the four checks inside the builder.
• You have no engineer to maintain code you would own after leaving.

Reasons to move

• You need control over hosting, logging, backups or where data is stored.
• Your logic outgrew what the builder handles reliably, such as complex payments or permissions.
• Customers or partners ask for security evidence you cannot produce on the platform.
• Performance under real traffic is becoming a problem.

If you move, the order I prefer is: fix the highest-risk issues in the existing code first, then export to GitHub and your own hosting, and only rewrite what is truly broken. A full rewrite is rarely the first step. Check what export options your builder offers, since they differ between tools. Lovable code, for example, can go to GitHub and your own hosting.

Want a second opinion on your app?

If you have a Base44 app heading toward real users, email me@filipeeduardo.dev with the link and a note on what it does, and I’ll tell you what I’d check first.