Is Base44 secure? Reported vulnerabilities, access rules and what to check in your app

The short version

Is Base44 safe? The useful answer comes in two parts.

The platform. Security researchers have publicly reported flaws in Base44 itself, most of them in 2025. The best known came from Wiz, which found that private apps could be joined using only their public app ID, and from Imperva, which found ways to steal sign-in tokens. In both cases the researchers said Base44 fixed the problem, and Wiz said there was no evidence that any customer was affected. Base44 says it holds SOC 2 Type II and ISO 27001 certifications, runs penetration tests and has a bug bounty program.

Your app. Most of what decides whether your app’s data is safe is in settings you control: who can open the app, the access rule on each table, whether backend functions check who is calling, where your API keys live, and who has admin rights. Base44’s own documentation says plainly: “You are responsible for your app’s security settings.”

This page lists the reported incidents with dates and sources, explains how Base44’s access rules work, and gives a checklist for your own app.

Reported security issues, with dates and sources

These are the issues reported publicly by security researchers and reputable press, as of October 2026. Each line describes what was reported, nothing more.

In the same Geektime article, Base44 said the Imperva issues were found and fixed in March 2025, when it had few users, and that the Wiz issue affected fewer than 3% of apps.

Two patterns run through these reports. The platform flaws were in sign-in and token handling, which Base44 operates and fixes centrally. The 2026 research, like the dispute over the Dos-Op findings, is about how individual apps were configured. That part is yours.

What Base44 handles at the platform level

According to Base44’s security page and security overview, as of October 2026:

• SOC 2 Type II and ISO 27001 certification, and a data processing agreement on request for GDPR.
• Encryption in transit (TLS 1.2 or newer) and at rest (AES-256). Stored credentials are encrypted with AWS Key Management Service, using a key Base44 manages; Enterprise workspaces can have a dedicated key.
• Penetration testing by internal and third-party teams, an invite-based bug bounty program, and 24/7 security monitoring.
• Rate limiting on all public endpoints.

The same documentation lists some limits worth knowing:

• Data is not end-to-end encrypted; Base44 says its admins can access your data if needed.
• Sign-in tokens are stored in the browser’s localStorage. HttpOnly cookies aren’t available.
• Per-app CORS settings aren’t available, and headers such as Content-Security-Policy and Strict-Transport-Security can’t be set per app. You can control embedding and browser-feature permissions.

How Base44’s access rules work

App visibility

Every app has one visibility setting: Public (anyone on the internet), Private (invited people only, sign-in required) or Workspace (your Base44 workspace, sign-in required). Private apps need a paid plan. A public app that doesn’t require sign-in can’t tell visitors apart, so any table it can read is readable by everyone.

Data access rules (row level security)

Each table has rules for Create, Read, Update and Delete (Managing data permissions). In the editor, each action can use these rule types:

If a person matches any one rule, they get access. Base44 sets rules automatically as the AI builds your tables and shows a Permission risks detected banner when it spots something too open.

Base44’s developer documentation shows what sits underneath. The rules live in each table’s schema as row level security, with optional field level security for single fields such as a salary. Conditions can compare a record to the signed-in user:

"rls": {
  "create": true,
  "read": { "created_by": "{{user.email}}" },
  "update": { "created_by": "{{user.email}}" },
  "delete": { "user_condition": { "role": "admin" } }
}

Denied reads return nothing, as if the records didn’t exist. Denied writes fail with a permission error. One exception matters: code in a backend function that uses Base44’s service role skips these rules entirely, so the function itself has to check who is asking.

What to check in your own app

Work through these on every app that holds anything personal or commercial. Base44’s security scan covers several of them and is free on every plan.

1. Visibility. Is the app public when it should be private or limited to your workspace? Anyone can find and open a public app, and the 2026 research above was about apps left public.
2. Every table’s rules. Look for All Users on Read for anything personal, such as orders, messages, form submissions or user profiles. Personal data usually wants Creator Only, or a field comparison. Then sign in as different roles in Preview and confirm each sees only what it should.
3. Public entities. Contact forms and sign-up tables often allow anyone to Create. That’s fine as long as Read, Update and Delete are restricted to your admin role.
4. Backend functions. The scan flags functions that return data without checking who is signed in (“Anyone can run this function”). Pay extra attention to functions that use the service role, and make webhook handlers verify the sender’s signature.
5. Secrets in frontend code. An API key written into a page or component is visible to every visitor. Keep keys in Base44’s secrets and call outside services from backend functions; the scan’s Exposed secrets check looks for this.
6. Credit-using features. The scan’s Credit protection check flags AI, image or email features that can be called from outside your app, where someone could spend your integration credits.
7. Admin roles and collaborators. Base44 adds collaborators to your app as Admin by default, and on public apps people with the User role can invite other users. Review your Users list, remove accounts you don’t recognize, and keep the Admin role to the people who need it.
8. Embedding. If your app has sign-in or payments, set embedding to No one, or to Only these sites if you embed it on your own website.

Run the scan again after any big change, such as new tables, new integrations or new permissions. Code-vulnerability scanning and the optional Wiz integration need the Builder plan or higher.

What changes when you run the app yourself

Moving an app off Base44 doesn’t make it secure, and it doesn’t make it less secure by itself. It changes who is responsible for which part.

• Your access rules come with you, including their mistakes. With Unbase44, every table moves with its access rules, and the Base44-compatible backend enforces them on your own server. A table that’s open to everyone on Base44 is open to everyone after the move. Fix the rules first.
• The platform work becomes yours. Base44’s certifications, penetration tests, bug bounty and 24/7 monitoring cover Base44’s platform. They don’t come with your hosting. On your own accounts, you or your developer keep the server and its dependencies updated, watch the logs and respond to problems. Your hosting provider covers its own layer.
• You can see and change everything. The server code sits in your own GitHub repository under the MIT license, with documentation, so a developer or security reviewer can read exactly how sign-in and access checks work.
• Your keys live in your accounts. Secrets sit in your hosting environment, and email and AI run on your own provider accounts. After the move, Revoke access on the app’s page deletes every key Unbase44 held.
• You choose where data lives. The region is whatever you pick for your hosting and database, which matters for GDPR and data residency.

If your app handles health data or other regulated information, the rules are stricter wherever it runs. Our HIPAA guide covers that case.