Is Base44 Safe? 7 Security Risks to Check Before Launch

Is Base44 safe to use?

Two questions hide inside that one. Is the Base44 platform safe, and is the app you built on it safe? They have different answers.

The platform side is in reasonable shape. Base44 says it is SOC 2 Type II and ISO 27001 certified, GDPR compliant, penetration tested by internal and third-party teams, and runs a bug bounty program. App data is encrypted in transit with TLS 1.2+ and at rest with AES-256, and backups are covered too. Wix bought Base44 in June 2025 for about $80 million, so Base44 is now part of Wix. Those certifications cover how Base44 runs its own systems. They do not certify your app.

Your app is the part to check, and Base44 says so in its own docs: "You are responsible for your app's security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish."

What Base44 secures for you

Here is what you get without doing anything, as Base44 documents it:

• Access rules on every table. Base44 sets up data permissions automatically as you build, with row-level and field-level rules enforced by the backend.
• A security scan on all plans, including free. It checks permissions, exposed secrets, backend functions, credit-using features, vulnerable packages and security headers. Static code analysis is added on Builder and above.
• Encrypted secrets. API keys saved as Secrets stay on the server and never reach the browser.
• Built-in sign-in. Email and password, Google, Microsoft, Facebook, Apple, and SSO through any OIDC provider.
• Rate limits. All public endpoints are rate-limited by default.

Two limits are worth knowing. The scan warns you at publish time but does not stop you from publishing, and it does not apply fixes on its own. And the scan does not look at Base44's hosting or the systems your app runs on.

Base44's security record

Two research teams have published platform flaws, both fixed.

Wiz Research, July 2025. Two undocumented endpoints, one to register a user and one to verify the email code, accepted requests without authentication. All they needed was the app's app_id, which is not secret: it sits in every app's URL and manifest file path. With it, an outsider could create a verified account on a private app, even one set to SSO-only sign-in. Wiz reported it on 9 July 2025, Wix fixed it within 24 hours, and Wix said it found no evidence of past abuse. The fix was made on Base44's side, so customers did not need to do anything.

Imperva, August 2025. Imperva published several flaws: an open redirect in the login flow that could send a user's access token to another site, stored cross-site scripting on app.base44.com made possible because a premium feature was only enforced in the browser, and the main Base44 login token being passed to user-built apps in the URL. Imperva says Base44 moved quickly to fix them.

A clean record would be better. A quick fix and a public write-up is what you want to see when something does go wrong.

Risk 1: Data tables anyone can read

This is the one that matters most. Every table in a Base44 app has rules for create, read, update and delete. The rule called All Users means anyone can perform that action, even without signing in. That is right for a product catalog. It is wrong for orders, messages or form submissions.

A softer version of the same problem: a table that is meant to be public, like testimonials or listings, with one field that holds an email, a phone number or a token. On a public app, anyone who can open it can read that field on every record.

How to check: In the app editor, click Dashboard, then Security, then Run Security Scan. Look at the Permissions and Private fields groups. Then open each table that holds personal data and read its Read rule yourself.

How to fix: Use Creator Only for personal data, so each person only reaches records they created. Use Entity-User Field Comparison for records assigned to someone, such as a task with an assigned_to field. Use User Property Check with User Role set to Admin for anything only your team should touch. For a sensitive field on a public table, the scan's fix adds a field-level rule so only the record's creator and your admins can see it. Run the scan again afterwards.

Risk 2: The app is public when it should be private

App visibility decides who can open your app at all. Public means anyone on the internet, with no sign-in required. Private means invited people only. Workspace means everyone in your Base44 workspace. Base44 picks a starting point for you and sets apps that look like websites to Public without login, so an internal tool that happens to look like a site can start out open.

How to check: Click Dashboard, then Overview, and read the App Visibility drop-down. Then open the app in a private browser window and see what a stranger sees.

How to fix: Set internal tools and client portals to Private or Workspace. Private apps are on paid plans only, and people need an invite to get in unless you turn on auto-admit. If the app must stay public, visibility is not your protection, so the table rules in Risk 1 have to carry the weight.

Risk 3: Access checks that only live in the interface

Hiding an admin page or a delete button in the interface does not stop anyone. Your app's pages talk to the backend through the Base44 SDK, and anyone can make the same calls from their browser. What the backend refuses is decided by the table rules, not by which buttons a user can see. Base44 itself got caught by this pattern: Imperva's stored XSS worked because a premium feature was only enforced in the browser.

A related trap: app users can edit the custom fields on their own profile. If a rule decides access from one of those fields, like a company field, a user can change it to another company's value and get that company's records.

How to check: For every screen that should be admin-only, find the tables it reads and writes, and confirm their rules say Admin, not All Users. In the security scan, look for the group called User fields users can change.

How to fix: Put the restriction on the table with a User Property Check, so the backend refuses the request whatever the interface shows. For profile fields, the scan's fix locks each field so only your app's editors can change it, and moves the code that sets it into a check that runs on the server. Test sign-up and onboarding afterwards.

Risk 4: API keys outside Secrets

When you connect Stripe, OpenAI or any other service, the key has to live somewhere. In Secrets, it is encrypted, stays on the server, and is read only by backend functions. Anywhere else, such as page code or a component, it can end up where visitors can read it. Base44's own guidance is blunt: never paste API keys into public code, visible components, or prompts. The one exception is when the AI chat asks you for a key: a key pasted at that prompt is saved as a secret for you.

How to check: The security scan has an Exposed secrets group that flags keys, passwords and tokens left where visitors could find them. Then click Dashboard, then Secrets, and make sure every service your app uses has its key listed there.

How to fix: Remove the key from wherever it was found. Add it under Dashboard, then Secrets, then Add Secret, and read it only inside a backend function. Since a key that was visible may already have been copied, create a new one with the provider and delete the old one. The Secrets page appears once your app has backend functions, which need the Builder plan or higher.

Risk 5: Backend functions anyone can call

Backend functions run your server-side logic, and each one gets its own web address. Called from your app, a function knows who the user is. Called directly over HTTP, as a webhook would, there is no signed-in user, and nothing stops a stranger from calling it unless the function checks. A function can also use asServiceRole, which skips every row-level and field-level rule you set. A function that uses it without checking the caller is a side door around Risk 1.

The same goes for features that spend your credits, such as AI calls, image generation or email. If they can be reached directly from outside your app, anyone who finds them can run them on your bill.

How to check: In the security scan, look under Backend functions for anything marked Anyone can run this function, and for an issue called Prevent unauthorized credit usage. In code, open Dashboard, then Code, then base44, then functions, and look for a check of base44.auth.me() near the top of each function.

How to fix: On an app that requires login, Fix with AI makes the function require a signed-in user and limits its data to that user. On an app without login, either switch the app to require login or verify the caller inside the function: a provider signature for a webhook, a shared secret for anything else. Both fixes can break a webhook or a signed-out page, so test those paths after.

Risk 6: Personal data going to more places than you planned

Your users' data does not stay in one box. By default, Base44 stores app data in the United States; EU, UK or Australian storage is on the Business and Enterprise plans. The built-in Invoke LLM integration sends prompts to a language model, and Base44's subprocessor list includes model providers such as OpenAI and Anthropic, plus services for email, SMS and analytics. Data is encrypted, but not end to end, so Base44 admins can access it if needed.

None of that makes Base44 unsafe. It means your privacy policy has to match what your app actually does.

How to check: List every integration your app uses and what user data each one receives. Compare that with Base44's subprocessor list and with your own privacy policy.

How to fix: Send AI features only the fields they need, not whole user records. Update your privacy policy to name where data goes. If your customers need data kept in the EU, check the data residency options on the Business and Enterprise plans before you sign them. Base44 offers a Data Processing Agreement on request.

Risk 7: The parts you cannot review or change

Some of your app's security is fixed by the platform, and you cannot inspect or adjust it. Base44 does not support self-hosting: exported code still depends on Base44 for data, logins, functions and integrations. Its security FAQ lists a few platform choices worth knowing: login tokens are stored in the browser's localStorage, HttpOnly cookies are not available, and Content-Security-Policy and Strict-Transport-Security headers cannot be set per app. CORS is managed at the platform level too.

For most apps that is a fair trade. For a client running its own security review, it means some answers come from Base44 rather than from you.

How to check: If a customer sends you a security questionnaire, mark which questions are about your app and which are about the platform. The Base44 Trust Center is where you request the SOC 2 report and find the platform answers.

How to fix: You cannot change these settings, so plan around them. Since tokens sit in localStorage, keep third-party scripts in your app to a minimum. Keep your own copy of your code through the GitHub integration, and read the Base44 pricing guide on what leaving the platform would take before a big client depends on it.

What to do next

Run the Base44 security scan, then go through the seven risks above with your app open in a private window. If you are still choosing a builder, the Base44 vs Lovable and Base44 vs Replit comparisons cover how each one handles this, and our Lovable security guide walks the same questions for Lovable.

BWorlds audits apps built with Base44 and other AI builders across security, reliability, data protection, performance, costs and code quality. Each finding comes with a plain-language diagnosis and a fix prompt you paste into Base44, and BWorlds checks that the fix landed. Once the app is live, it watches uptime, errors and session replays through the LaunchKit SDK, and a GitHub connection picks up code changes. To start, sign up free, paste your app's link and get a first read in minutes, before you connect any code. Connecting the code gives you the full audit.