Is my Base44 app secure? A plain check before you launch

01

Run Base44’s security scan, and read every finding

Start with what Base44 already gives you. Click Dashboard, then Security, then Run Security Scan. Base44’s scan docs say it is available on every plan, including the free one, and checks for seven kinds of issue: data permission issues, exposed secrets, unauthenticated backend functions, credit protection, app dependencies, code vulnerabilities, and security header recommendations. The code vulnerability part needs the Builder plan or above. If your workspace already uses Wiz, you can also connect it and see its findings on the same page.

Three things in those docs are worth knowing before you click anything. The scan doesn’t apply fixes on its own, so read what each one changes. When you publish, the publish panel shows your security status, but in Base44’s words, “It warns you, but it doesn’t stop you from publishing.” And an issue you mark as Ignore stays ignored on every later scan, so only ignore something you understand. Each fix creates a checkpoint in the AI chat first, so if a fix breaks a page, you can roll it back.

Run it again after any big change, like a new table, new permissions or a new integration. Then keep going, because the scan checks patterns. It doesn’t know who your app is for.

02

Decide who the app is for before you share the link

This sounds too simple to matter. It is the one that got thousands of vibe-coded apps into the news. In May 2026, WIRED reported that the security firm RedAccess had found more than 5,000 apps built with Lovable, Replit, Base44 and Netlify with “virtually no security or authentication of any kind,” many of them found with ordinary searches for the builders’ hosting domains.

Open Dashboard, then Overview, and look at App Visibility. Base44’s access docs list three levels:

• Public: anyone on the internet can open it. Base44’s FAQ adds that on a Public app, “anyone can create an account from your register page and sign in.”
• Private: only people you invite, and they have to sign in. This needs a paid plan.
• Workspace: everyone in your Base44 workspace, signed in.

Base44 picks a starting point for you. Apps that act like public sites, such as landing pages or portfolios, are set to Public without login automatically. So ask the plain question: who is this app for? If the answer is “my team” or “a few clients,” it shouldn’t be Public. If the answer is “anyone who signs up,” Public is right, and then the rules on your tables are the lock. If you’re not sure what yours is set to, ask the AI chat in Discuss mode:

Tell me this app's current App Visibility setting (Public, Private or Workspace), whether people have to sign in, and whether anyone can register on their own. This app is for: [describe it, e.g. "only my team" or "anyone who signs up"]. If the setting doesn't match that, tell me what to change before you change anything.

A bad result here is an app full of customer or team data that says Public and lets anyone register. Fix that before anything else.

03

Look at who can sign up, and who already has

Open Dashboard, then App Users, and read the list slowly. Are there accounts you don’t recognise? Old test accounts with the Admin role? People who left the project? You can remove anyone from the same screen, and Base44 keeps removed users under Recently deleted in case you remove the wrong one.

Two details from Base44’s access docs are easy to miss. On a Public app, people with the ordinary User role can invite other people, while on a Private app only admins can. And anyone you add as a collaborator, so they can help in the editor, is given the Admin role in your live app by default. If they only need to build, check their role afterwards.

Then open the Authentication settings and look at which sign-in methods are switched on. Turn off any you don’t use. If your app is meant for one company, SSO with that company’s accounts is the strongest option Base44 offers. That was also the setting the 2025 flaw got around, which is why we still check this list by hand.

04

Give every table a rule, and don’t leave personal data on All Users

This is the check we would bet on. Broken access control sits at the top of the OWASP Top 10, and on Base44 it lives in one place: the permissions on each table. Base44’s developer docs for creating entities put the risk in one sentence: “If no RLS is defined, all records are accessible to all users.”

Click Dashboard, then a table under Data, then Permissions in the top right. A warning icon on that button means Base44 already thinks something is off. The permissions docs describe four rules:

• All Users: anyone can do this, “even without signing in.” Right for a product catalogue or blog posts. Wrong for anything personal.
• Creator Only: people only reach records they created. The usual choice for orders, messages and form submissions.
• Entity-User Field Comparison: a field on the record has to match the signed-in person, like an assigned_to field matching their email.
• User Property Check: only people with a certain role or property, like Admin, can do it.

Go through every table and say out loud who should read it. A contact form is a good example from Base44’s own docs: All Users on Create so anyone can send a message, and an admin-only check on Read, Update and Delete so only you see them. If a person matches any one rule, they get in, so one stray All Users on Read opens the whole table no matter what else is there. That is the bad result to look for. If you see a Permission risks detected banner, read the recommendation before you apply it. To set everything in one go, describe your app in your own words:

Here is who should see what in this app: [describe it, e.g. "each customer sees and edits only their own bookings; staff can see all bookings; only admins can delete"]. Go through every data table and set Create, Read, Update and Delete so that rule holds. Use Creator Only or an Entity-User Field Comparison for anything personal, and a User Property Check for admin-only actions. Don't use All Users on Read for any table that holds personal data. List every table, what its rules were, what they are now, and which ones still allow All Users on purpose.

Two more things. Base44 locks down the built-in Users table, so if a member profile page only works for admins, don’t open that table up; the access docs suggest a separate UserProfile table instead. And if you or a developer ever change permissions through the API, Base44 warns that the change can be replaced the next time the table’s file is saved. Make permission changes on the Permissions page or through the AI chat, so they stick.

05

Try to open another person’s record on purpose

Check 4 is about reading the rules. This one is about seeing them hold. The mistake behind most data leaks in apps like these has a name, broken object level authorization, and it looks like this: someone is signed in, opens their own booking, changes one thing in the address, and is looking at somebody else’s.

Base44 makes this test easy. On a table’s Permissions page, click Test Permissions in preview, or use Act as a user from the editor’s menu, and pick a person. You see the app exactly as they do. Make two sample users, add a record as the first, then switch to the second and try to reach it: from the list, from the detail page, and by pasting the first person’s address for that record. Base44’s security docs say a blocked list comes back empty and a blocked single record looks like it doesn’t exist, so “nothing there” is the good result. Seeing the first person’s record is the bad one.

Do the same with an ordinary user against every admin screen. A hidden menu isn’t a lock; the rule on the table has to say no. Base44 warns that anything you change while acting as someone is saved to their data, so use sample people, or turn on a separate test database first.

06

Knock on your backend functions without signing in

Backend functions are where table rules can quietly stop applying. Base44’s security docs say a function can use base44.asServiceRole, which “bypasses both RLS and FLS entirely,” and that “your function is responsible for any access checks it needs.” The functions docs add that each function has its own web address, and when it’s called directly, with curl or as a webhook, “there’s no authenticated user context.” Put those together and a function that reads with the service role and never asks who is calling will hand anyone every record.

The scan’s Unauthenticated backend functions section is the first place to look. If your app requires login, each open function shows as Anyone can run this function, and Fix with AI makes it require a signed-in user. Base44 warns that this can break a page for signed-out visitors, a webhook, or an integration that calls the function, so test those afterwards. If your app doesn’t require login, every function is open by design, and the riskier ones, such as those that write data or use AI, are marked High.

To see it for yourself, find your function names on Dashboard, API, under Backend Functions. Pick one that only reads data, and call it the way a stranger would, with no login:

# Replace YOUR-APP and FUNCTION_NAME. Only for a function that reads data.
curl -i -X POST https://YOUR-APP.base44.app/functions/FUNCTION_NAME \
  -H "Content-Type: application/json" -d '{}'

A function that checks who is asking, like the example in Base44’s own docs, answers 401 with Unauthorized. A 200 with real records in it is the bad result. This really runs the function, so don’t do it for one that sends email, writes records, takes payments or calls an AI model; for those, read the scan’s list and ask the AI chat to show you the check at the top of the code. To fix them all at once:

Go through every backend function. For each one that reads or changes user data, make it call base44.auth.me() first and return 401 if there is no signed-in user, then only read or change records that belong to that user. Don't use asServiceRole unless the function truly needs it, and if it does, check ownership in the code before touching any record. For webhooks that must stay open, verify the caller with the provider's signature or a shared secret instead. List every function, whether it needed a check, and what it checks now. Don't change anything else.

07

Keep keys in secrets, and paid calls out of the browser

Keys for OpenAI, Stripe, Resend or anything else belong in secrets. Base44’s API reference says secrets are made available to backend functions as environment variables, and the CLI docs show how functions read them. The scan’s own FAQ gives the rule in one line: handle all requests to third-party services in backend functions and store the keys as secrets. A key written into a page is a key every visitor can download.

There is a cost side to this too. The scan has a Credit protection check for AI, image and email features that can be reached from outside your app, including AI calls made from your pages in the browser. Someone who finds them can spend your credits. If you see Prevent unauthorized credit usage, take it seriously, and fix it before you share the link anywhere busy.

Find every place the pages of this app hold an API key, token or password for another service, or call a paid service (AI, email, image generation) straight from the browser. Move each of those calls into a backend function, store the key as a secret, and read it there. Remove the key from anything a visitor's browser downloads. List what you moved. Don't change anything else.

Then check what your live app really ships. On your own computer, this downloads the scripts your homepage loads and searches them for key-shaped strings:

APP=https://YOUR-APP.base44.app

# 1. The scripts your homepage loads
curl -s "$APP/" | grep -oE '(src|href)="/[^"]+\.js"' | cut -d'"' -f2 | sort -u \
  | while read -r f; do curl -s "$APP$f"; done > app.js

# 2. Anything shaped like a secret key
grep -ohE "sk-(proj|ant)-[A-Za-z0-9_-]{20,}|sk_live_[A-Za-z0-9]+|rk_live_[A-Za-z0-9]+|whsec_[A-Za-z0-9]+|AKIA[0-9A-Z]{16}|re_[A-Za-z0-9]{8}_[A-Za-z0-9]{20,}" app.js | sort -u

Nothing printed is what you want. A real key in the output means you should treat it as already public. Rotate it at the provider first, then put the new one in secrets and move the call into a backend function. Our guide to leaked API keys in your frontend bundle has a longer script that follows every file a page loads later, and the order to rotate in.

One more key to guard: the personal access tokens your app’s API page asks for. Base44 says they work like a password for your app’s data and warns against pasting them into an AI chat, a shared document or a screenshot. If one gets out, delete it on the access tokens page and make a new one.

08

Turn on the browser protections Base44 lets you set

Headers matter less than everything above, and a missing one won’t leak data on its own. Base44 is unusually clear about what you can set. Its security overview says you can choose which websites may show your app in an iframe and keep content from other sites from using the camera, microphone and location, and that “Other HTTP-level headers, such as Content-Security-Policy and Strict-Transport-Security, are not configurable at the individual app level.” CORS is managed by Base44 too, and its public endpoints are rate-limited by default.

So turn on what you can. Click Dashboard, then Settings, and under Browser Security set iFrame embedding to No websites unless you really embed the app somewhere, and switch on Protect camera and location. The scan docs say these are the two header settings the scan checks. Then see what your live app sends:

curl -sI https://YOUR-APP.base44.app \
  | grep -iE "^(x-frame-options|content-security-policy|permissions-policy|strict-transport-security|x-content-type-options|referrer-policy)"

One detail from the same overview is worth knowing: Base44 stores sign-in tokens in the browser’s localStorage, and HttpOnly cookies aren’t available. That means any script running on your page could read them, which is one more reason not to paste third-party scripts or widgets into your app casually. If you later put your own domain behind a proxy that can add headers, our security headers guide has a tested starter policy, and MDN explains what each part does. Base44’s domain docs cover connecting your own domain.