Is your Base44 app secure? Take control before it's hacked

Your app is live, and it holds your clients' records, your team's payroll, your patients' or your students' details. Then somebody asks whether it's secure. Usually it's a client's IT team, a lawyer, or a company you want to sell to, with a security questionnaire. Or you run Base44's security scan and it comes back with twenty issues on an app that passed last week. Or a tester makes himself admin, or a user sees another user's records, and now you need to know whether your app is actually secure.

Your app is only as secure as the platform it runs on

Base44 gives you two things: an AI builder, and a system that runs your app. What the builder makes is your app itself: the screens, the data, the rules for who can see which records, the backend functions. That's what you work on in the chat, and it's what Base44's security scan checks.

The system your app runs on is Base44's platform: the login, the sessions that keep your users logged in, the database, the servers, and where your files are served from. Base44 wrote all of it, runs it on its own servers, and it's the same code for every Base44 app. You can't see it or change it, and Base44's terms don't even let you test it.

So even if your app passes Base44's security scan, a hole in Base44's platform can still let strangers see your users' data.

The worst holes were in Base44's platform

Here are the big ones since 2025, and Base44's scan never showed a single one of them:

1. Anyone could register on any private app (July 2025). Two of Base44's sign-up addresses accepted anyone. With nothing but an app's id, which anyone could find in the app's page, a stranger could create an account on a private company app and get in like any member, even with sign-up switched off or the app behind company sign-on. Wiz, a security firm, found the two addresses listed on Base44's own public API pages. Nobody knows how long the hole had been there, or who got in before Wiz found it.
2. Your users' login tokens could be stolen (found March 2025, disclosed August). A crafted link could send a user's login token to an attacker's site, and a hole on app.base44.com, where you and your users log in, let a script read tokens straight out of the browser. Imperva, another security firm, found both in March. Base44's first fix still let the attack through, and nobody outside Base44 heard about any of it until Imperva published it in August.
3. Anyone who knew your app's id could see every change to its data (May to September 2026). Base44's realtime feature, the one that updates screens live, sent every record anyone created, changed or deleted to anyone who connected to it, logged in or not. A team found it on their own app and reported it in August. The hole had been there since at least May.
4. Builders opened their editor and found someone else's codebase in it (July 2026). Several people reported it the same week, confirmed each other's reports in Base44's community, and got no answer from support while it was happening.
5. Row-level security rules that did nothing (until September 2026). Base44's own AI writes row-level security rules like “show a record only if its organization matches the user's organization”. When a user had no organization set, Base44 didn't deny the request. It returned every record. On one real company app, a user who should have seen nothing saw all 578 records of both companies, with no error and nothing on the security page to say the rule wasn't working. It worked like that until September 2, when one line in Base44's changelog said it doesn't anymore.

Each of these holes was there until somebody happened to find it, and nobody knows who found it first. And these are only the holes somebody happened to look for. Base44's terms don't let anyone look for the rest.

Base44 likes to point to its certificates, SOC 2 Type II and ISO 27001. It got them in January 2026, and three of these five holes were found after that.

What you can't change from inside Base44

It's helpful to go through this the way a security questionnaire does, the form a client's IT team or a partner sends before they trust your app with their data. It's the standard list of what security means for an app: how people log in, how long they stay logged in, who can reach the data, whether it's backed up, who has admin access. Here's what you'd have to answer today:

• Base44's admins can see your data. It isn't end-to-end encrypted, and two builders found an @base44.com account listed as an admin of their app that they never added. Base44 also holds the key that encrypts your app's secrets, unless you're on Enterprise.
• Your users' data can be used to train AI. On every plan except Enterprise, that includes what people type into your app's forms, and there's no switch to opt out. Base44's terms also give it a permanent license to your data, including to share it with third parties and to use it in its own marketing, and the outside companies it may hand data to include a Chinese AI provider.
• You're not allowed to test it. Base44's terms forbid probing, scanning or testing the platform your app runs on. So you can't get a real penetration test of your app, which is the report a client's IT team asks for.
• There are no backups below the Elite plan. Elite keeps 7 days, Business and Enterprise keep 30, and the files your users uploaded aren't in any of them. Base44's terms still say backing up your data is your job.
• A password reset doesn't log anyone out. A login lasts up to 90 days, changing the password doesn't end it, and there's no button to log everyone out. If an account gets hacked, Base44's support tells you to delete the user and invite them again.
• Your users can't have two-factor login. Base44 has it for your own Base44 account, not for the people who log into your app.Why no setting, function or code screen can add it, and how 2FA, phone login or SSO gets added after the move
• Your users' login token sits where any script on the page can read it. It's kept in the browser's local storage and passed in the address bar after login, and Base44 doesn't offer the kind of cookie a script can't read.
• You can't add the security headers a reviewer checks for. Your app sends no Content-Security-Policy, the header that limits which scripts can run on your pages, and Base44 gives you no way to add one.
• Anyone can still reach your app at its .base44.app address. Every app is live on it from the day it's created, and there's no setting to turn it off, so a firewall you put in front of your own domain doesn't cover it.

And if something goes wrong in the platform, it's on you. By Base44's terms, the platform comes as is, with no promise about security, and Base44 isn't responsible if someone gets into its servers. So if a hole in Base44's platform leaks your users' data and it costs you clients, a lawsuit or a fine, the most Base44 will ever pay you to make up for it is what you paid Base44 over the last year, or $100 if that's more. And if your users sue Base44 over the leak, you have to pay Base44's lawyers and whatever Base44 has to pay them.

Why every Base44 app has the same holes

Every Base44 app runs on the same shared platform, in the US. Every .base44.app address points at the same server, and so does your custom domain. Your app doesn't have its own server, database or login system. It's a row in Base44's system, run by Base44's code, next to thousands of other apps. That's why one bug could let strangers into every private app at once, and why a flaw in Base44's login was a flaw in yours.

Holes like these usually don't happen, because usually nobody runs their whole business on a vibecoding platform. A normal app has its own login, sessions, headers, database and server, and its owner can see and change every one of them.

How to make your app as secure as Base44 allows

On Base44 you can't change any of Base44's problems. What you can do is make your own app as secure as the platform allows, and three things do most of it:

1. Run Base44's security scan and fix what it finds. It checks your app for tables anyone can read, functions anyone can call, and profile fields your rules rely on that users can change themselves. Fix carefully on a live app: locking a function that “anyone can run” also breaks the public page or the webhook that was calling it, and on one builder's app the scan's fix rewrote the rules on the User table and took the live app down for nine hours. And run it again after every change, because each fix can bring up new findings.
2. Get a security audit. For a few hundred dollars, an auditor goes through your rules, your functions and your settings and tells you what's wrong with them.

3. Move your most sensitive data to another database. Base44 itself suggests this: keep that data somewhere else and leave the rest of the app where it is. That data is then out of Base44's database, but your users still log in through Base44, and everything the app does with a record, its functions, emails and uploads, still runs on Base44.

   Why a Base44 app can't be made HIPAA compliant by moving its data

Do all three, and your app is as secure as it can be on Base44. But all three only touch your own app. None of them changes anything in the platform under it: the login, the sessions, the token, the headers, Base44's admins, the backups, the servers. An auditor can't even look at the platform, because Base44's terms don't allow it. And the platform is where the worst holes have been.

The real fix is getting the app off Base44, and most people assume that means rebuilding it from scratch. Rebuilding works too, but it's weeks of development to end up with the app you already have. And Base44's export doesn't help with the rebuild either: it gives you your screens and your functions' code, but the login, the sessions and the database and everything else Base44's servers do to run your app stay on Base44.

How to take control of the platform your app runs on

You don't need a new app for this. The one you have works, people use it, and the only thing wrong with its security is the platform it runs on.

This is exactly why I built EscapeBase44. I got stuck on Base44 with an app of my own, and ended up spending months reverse-engineering Base44's entire backend until I could actually escape. Then I automated this whole process. EscapeBase44 moves your Base44 app and the platform it runs on onto normal providers under your own accounts. The backend that runs your app's login, sessions and database, with all of its security code, becomes your own code, and you control every line of it. Every screen, every record, every user with their password, the files, the backend functions and the permission rules move with it. You log in with Base44, pick your providers, and the migration runs by itself.

EscapeBase44 isn't another platform for your app — you don't replace Base44 with EscapeBase44. It's a one-time move. When the migration finishes, EscapeBase44 is completely out of the picture: there is no access to your app, to your accounts or to your data. And your app no longer depends on any external platform: not on Base44 and not on EscapeBase44. Your app is on your own accounts, run by your own code which you now fully control, and the only admin is you.

The thing that actually makes your app secure here is the providers, not EscapeBase44. Your app lands on standard providers like AWS or Google Cloud, the same ones the whole industry and the most sensitive organizations run production apps on, on accounts that are yours. Go back to that questionnaire. Here's what you'd answer after the move:

• No outside company has access to your app. No platform admins, no support accounts, no company that can read what your users type. Your app doesn't share a login system with thousands of other apps either, so a bug in somebody else's platform can't affect it. The only people who can see your data are the ones you give access to.
• You can test it. AWS and Google Cloud let you run penetration tests against your own apps without asking anyone. Hire a pentester, hand them the app and the code, and get the report a client's IT team wants.
• Backups, a firewall and logs are settings on your own account. With your database on your own server it's already backed up every night and the last seven days are kept; on a managed database like MongoDB Atlas, backups are a setting on its paid tiers. You can put a firewall or Cloudflare in front of your own domain, with no Base44 proxy in between, and you can read your own logs.
• The server keeps itself patched. Its operating system installs security updates by itself, every day.
• Every setting Base44 kept from you is now yours. Your app's login, sessions and database now run on code in your own GitHub, and every security setting that used to be Base44's is in it: how long a login lasts, where the token is kept, which headers the app sends, who can sign up, whether a password reset logs everyone out. On day one they're set exactly the way Base44 had them. From then on you can change any of them, and you can finally read and audit the security code, which Base44 never shows you. Want two-factor login for your users? It's your login system now, so you can add it.

And you can keep building. Your app is now a normal codebase in your own GitHub, and nothing in it depends on EscapeBase44. EscapeBase44 comes with an AI builder that works on that codebase the way a developer would: you chat with it like you did on Base44, and it reads and edits your own code, backend included. On Base44 the builder was the only way into your app, and the app couldn't run without the platform behind it. Here the builder is a tool on top of code that is yours, and the app runs with or without it. Ask it for a full security review, who can read, create, edit and delete each record, whether every function checks who's calling it, whether any key is exposed in the frontend, and then tell it to fix what it finds. Or use Claude Code, Cursor, or a developer instead. It's your code now.

Base44 security FAQ

• Are Base44 apps secure?

  Only as secure as the platform they run on. You can get your own app's settings right, but its login, sessions and servers are Base44's, and that's where the worst holes have been: strangers signing up to private apps, login tokens leaking, live data feeds anyone could listen to. You can't see, change or test any of that while the app is on Base44.

• Has Base44 been hacked or had a data breach?

  Its platform has had holes that let strangers into private apps. In 2025 security firms found that anyone could sign up to a private app with just its id and that login tokens could leak to an attacker's site, and in 2026 builders found a live data feed anyone could listen to and someone else's code in their own editor. Each hole was there until somebody happened to find it, and nobody knows who used it first.

• Can Base44 employees see my app's data?

  Yes. Your data isn't end-to-end encrypted, Base44 holds the keys, and its admins can see it. Builders have found @base44.com accounts listed as admins of their app that they never added.

• Where is my Base44 app's data stored?

  On Base44's servers in the United States, next to every other Base44 app's. Every app's address points at the same shared system, and your app has no server or database of its own.

• Is my Base44 app's data encrypted?

  Only partly: at rest and in transit, but not end to end. Base44 holds the keys (your own key is an Enterprise option), which is why its admins can see your data.

• Does Base44 have two-factor authentication for my app's users?

  No. Base44 has 2FA for your own Base44 account, not for the people who log into your app, and there's no setting to add it.

• Does Base44 back up my app's data?

  Only on the Elite plan and above: Elite keeps 7 days of backups, Business and Enterprise keep 30, and uploaded files aren't in any of them. Below Elite there's no backup, and Base44's terms say backing up your data is your job.

• Does Base44 sell my data?

  Base44's terms give it a permanent license to your data, including to share it with third parties, train AI on it and use it in its own marketing. Its list of outside companies that may handle your data includes a Chinese AI provider.

• Does Base44 use my users' data to train AI?

  Yes, on every plan except Enterprise, including what people type into your app's forms, and there's no switch to opt out.

• Is Base44 SOC 2 compliant, and does that make my app secure?

  Yes, Base44 has had SOC 2 Type II and ISO 27001 since January 2026, and no, that doesn't make your app secure. The certificates say how Base44 the company runs its processes, and they don't give your app a single setting it didn't have. Three of the platform's five big holes since 2025 were found after Base44 got them.

• Can I run a penetration test on my Base44 app?

  Not a real one. Base44's terms forbid probing, scanning or testing the platform, which is where your app's login, sessions and database access run, so a pentester can only check your own rules and functions. On AWS or Google Cloud you can test your own app without asking anyone.

• Why does my Base44 security scan keep finding new issues?

  Because it scans a live app whose rules the AI keeps editing, and because its own fixes often create the next finding. People fix five issues, get a clean scan, and see six new ones minutes later. It also only checks your app itself, never the platform it runs on.

• Can other Base44 users see my app's data?

  Not through your app, if its permission rules are right. But your app shares Base44's login system and servers with every other app, and in July 2026 builders opened their editor and found someone else's code in it.

• Is my app more secure after I move it off Base44?

  Yes. Nobody from Base44 is inside it anymore, a bug in Base44's login can't affect it, and you're allowed to test it. Its settings start out exactly as Base44 had them, and from then on every one of them, from sessions to headers, is in your own code where you can change it.