Is Base44 Safe? Base44 App Security Before You Go Live

What Base44 Is, and What It Secures for You

Wix announced on 18 June 2025 that it had acquired Base44, a platform for building apps from plain-language instructions without code, and said Base44 would keep running as a distinct product and business. Each app gets a free built-in address like myapp.base44.app when you create it. Nobody else can open it until you publish, and from then on your visibility setting decides who gets in.

Base44's security overview splits the work in two:

Source: Base44 security overview, read on 24 October 2026.

The same page is blunt about the right-hand column: "You are responsible for your app's security settings."

Who Can Open Your App: Visibility and Login

Visibility is set under Dashboard, Overview, App Visibility. Base44's access guide lists three levels:

From the same guide:

• The default may be Public. Base44 sets apps that act like public sites, such as landing pages, to Public with no login. Check the setting rather than assume.
• Private needs a paid plan (checked on 24 October 2026).
• Login is not the same as trust. On a Public app, anyone can create an account from your register page and sign in. A members-only page keeps strangers out only until they sign up.
• The badge lets people copy your app. The Edit with Base44 label sits at the bottom right of public apps, and anyone who clicks it can copy your app into their own account. Hiding it, on the Starter plan or above (checked on 24 October 2026), also stops the copying.

In July 2025, security researchers reported that anyone who knew a private app's ID, visible in its URLs, could register on it through undocumented endpoints, even on SSO-only apps. Wix fixed it within 24 hours, and Base44's statement said it had so far found no evidence of customer impact. The lesson: visibility is a platform lock, so set data rules that hold if it ever fails.

Data Permissions: Who Can Read Each Record

Base44 sets up data permissions automatically as it builds your tables, and warns that wrong rules let the wrong people view or change data. Each table has a Permissions page covering Create, Read, Update and Delete, with four rule types:

• All Users: anyone can perform the action, even without signing in. Right for a product catalogue, wrong for orders or messages.
• Creator Only: people reach only the records they created.
• Entity-User Field Comparison: a field on the record must match the person's account, such as assigned_to matching their email.
• User Property Check: only people with a set property, such as the Admin role.

A person who matches any one rule gets access, so a single loose rule opens the whole table. Developers can see the same rules written into the table's schema, as Base44's row level security docs show:

// BAD: true allows all users to read, update and delete every order
{
  "name": "Order",
  "properties": {...},
  "rls": {
    "create": true,
    "read": true,
    "update": true,
    "delete": true
  }
}

// GOOD: people read and edit only their own orders, only admins delete
{
  "name": "Order",
  "properties": {...},
  "rls": {
    "create": true,
    "read": {"created_by": "{{user.email}}"},
    "update": {"created_by": "{{user.email}}"},
    "delete": {"user_condition": {"role": "admin"}}
  }
}

Multi-tenant apps have one extra trap: app users can change the custom fields on their own profile, per Base44's scan docs. If a rule relies on one, such as a company field, a user can switch it to another organisation's value and get that organisation's access. The scan lists these under User fields users can change.

To test, click Test Permissions in preview on a table's Permissions page, or use Act as a user with a test account. A blocked list comes back empty, not as an error. Loose rules here are the same class of problem as missing Supabase Row Level Security and the Lovable BOLA breach.

Backend Functions Have Their Own Web Address

Backend functions run code that should stay out of the browser, such as API calls that need a secret key. They need the Builder plan or higher (checked on 24 October 2026). Per the developer docs, each one gets its own endpoint at https://<your-app-domain>/functions/<function-name> that can be called directly.

A direct call carries no signed-in user. For those calls the docs tell you to use asServiceRole, and service role access skips every access rule on your tables. The function has to do its own checking:

import { createClientFromRequest } from "npm:@base44/sdk";

// BAD: no sign-in check, and asServiceRole skips every access rule
export default async function (req: Request): Promise<Response> {
  const base44 = createClientFromRequest(req);
  const { orderId } = await req.json();
  const order = await base44.asServiceRole.entities.Order.get(orderId);
  return Response.json(order);
}

// GOOD: check who is calling, then read with their own permissions
export default async function (req: Request): Promise<Response> {
  const base44 = createClientFromRequest(req);
  const user = await base44.auth.me();
  if (!user) {
    return Response.json({ error: "Unauthorized" }, { status: 401 });
  }
  const { orderId } = await req.json();
  const order = await base44.entities.Order.get(orderId);
  return Response.json(order);
}

The security scan checks this for you. On an app that requires login, it lists functions that skip the check as Anyone can run this function, and Fix with AI makes them require a signed-in user. Test webhooks and signed-out pages afterwards, as the fix can break them. On an app with no login, anyone can call your functions, so verify the caller inside each one: the provider's signature for a webhook, a shared secret for anything else.

The scan also flags AI, image or email features that can be reached from outside your app, under Prevent unauthorized credit usage, because a stranger could spend your integration credits.

Secrets, API Keys and Integrations

Base44's integrations guide says app secrets are encrypted, stay on the server and never reach the browser. The same guide adds:

• Paste a key into the AI chat only when it asks. It is then saved as a secret for you. Base44's AI integrations guide adds that keys never belong in public code, visible components or prompts.
• Editors can manage secrets. Anyone who can edit your app can see the first 10 characters of long secrets and add, change or delete them. Keep the collaborator list short.
• Publish after you rotate a key. The live app keeps the values it had when you last published.
• Shared connectors share data. With a shared connector, everyone who uses your app shares that one connection and its data. Pick Read-only where the connector offers it.

Guard two more doors. The access token from your app's API page gives access to its data, so keep it out of chats and screenshots. And App MCP in its public, no sign-in mode gives anyone read-only access to every table you enable.

Custom Domains, Headers and Login Tokens

Custom domains need the Starter plan or higher (checked on 24 October 2026), and Base44 issues and renews the SSL certificate for you. A domain is branding, not a lock: Base44's own troubleshooting tip is to open the built-in .base44.app address when a custom domain fails, so that address keeps serving your app.

Browser protections live on the Browser Security card in your app's settings. You choose which websites may show your app in an iframe and can turn on Protect camera and location. The scan flags a missing X-Frame-Options or Permissions-Policy header, and rates it high if your app has login or payments. Base44's security overview adds that Content-Security-Policy and Strict-Transport-Security cannot be set per app. Our guide to missing security headers explains what each one does.

Base44 stores login tokens in the browser's localStorage, and HttpOnly cookie storage is not available. OWASP's HTML5 guidance advises against keeping session identifiers there because JavaScript can always read them, so one cross-site scripting bug could expose them. Treat any page that shows HTML written by your users with extra care.

Your Base44 Launch Checklist

1. Confirm App Visibility on the dashboard Overview is what you intend.
2. If anyone can sign up, write your data rules for strangers, not just friends.
3. Open every table's Permissions page. Personal data should never use All Users on Read.
4. Lock any profile field your rules depend on, then use Act as a user to check each role sees only its own records.
5. Make sure every backend function checks the caller, especially any that use asServiceRole.
6. Move every key into Secrets, and publish again after rotating one.
7. Review collaborators, shared connectors and App MCP table access.
8. Set iframe embedding and turn on Protect camera and location.
9. If you collect names or company details at sign-up, publish a privacy policy. Base44's login guide notes that Google OAuth requires one.
10. Run Dashboard, Security, Run Security Scan, fix or acknowledge every finding, and scan again after changes. A risky status at publish warns you but does not stop you.

Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your live Base44 app and, if you sync it to GitHub (Builder plan and above, checked on 24 October 2026), its repository, and flag missing security headers, SSL problems, console errors, missing privacy and terms pages, leaked secrets and vulnerable dependencies, with specific file paths and line numbers. Free to sign up.

For checks that apply to any AI-built app, see our vibe coding security checklist and our Lovable security guide.

FAQ