Reeve Security basics
Base44 security scan: the one thing only it can see
The Base44 security scan checks seven kinds of problem from inside your app. Here is the half it reads that nothing outside can, and the half it never looks at.
In short
- The Base44 security scan runs from inside your project and checks seven kinds of problem, from data permission rules to the libraries you depend on. It is free on every plan, and one of the seven only runs on Builder and above.
- On a Base44 app it is the only scan that can answer the question people actually mean by "is my app safe": whether a stranger can read your data. We graded 5,442 live Base44 apps and could ask 2 of them.
- What it has no reason to read is the page your visitors download. In 95 of those 5,442 apps, a Google API key was sitting in it.
You open your Base44 app's Dashboard, click Security, press Run Security Scan, and a few seconds later a list comes back. Or nothing does. Either way you are holding a result and wondering whether that was the whole check.
Most write-ups of this get it backwards. The usual argument is that a scan from inside your project cannot see what the internet sees, so the outside one is the one to trust. On Base44 that is the wrong way round for the half that matters: the Base44 security scan is the only thing that can check whether a stranger can read your data, and we can show you we cannot. We tried on 1,466 Base44 apps and got an answer from two of them.
So this is a division of labour. One scan works inside the building. The other stands on the pavement and reads what gets handed out the front. Both are worth doing, and on Base44 the inside one is doing the heavier half.
What does the Base44 security scan check?
Seven kinds of problem, read from inside your project. It never fetches your published address.
| What it checks | What that means | Plans |
|---|---|---|
| Data permission issues | A data table with no permission rules on it, or people with more access than they should have | All |
| Exposed secrets | API keys, passwords or tokens left somewhere app visitors could reach them | All |
| Unauthenticated backend functions | Something behind the scenes handing out data without checking who is asking. Titled "Anyone can run this function" | All |
| Credit protection | Your AI, image or email features reachable from outside your app, so someone else can spend your credits | All |
| App dependencies | A third-party library with a known security issue, with the version to move to | All |
| Code vulnerabilities | Patterns in your own code: missing access checks, unsafe handling of what a user typed | Builder and up |
| Security header recommendations | Two browser protections, iframe embedding and unused browser features | All |
All of that was read off Base44's own documentation on 10 October 2026, from the
Running a security scan and Base44 security: An overview pages. Three things
in there are worth knowing before you rely on the result:
- The scan never applies a fix by itself. You press Fix, and Base44 writes the change into your app's AI chat with a checkpoint before it, so a fix that breaks something can be rolled back from the chat.
- The Fix with AI button on an unauthenticated function rejects any caller with nobody signed in. Base44 says in the same breath that this can break a page you show to signed-out visitors, a webhook, or an integration that calls the function. Test those paths afterwards.
- It warns at publish and does not stop you. The publish panel shows a Security status, which Base44 describes as warning you without stopping you from publishing.
The one thing only it can see
Whether the people using your app can reach data that is not theirs. On a Base44 app, nothing outside the platform can check that.
On most builders your app talks to its database straight from your visitor's browser. The database therefore has a public address, your page carries that address, and anybody can lift it out and start asking questions. Whether they get answers depends on a per-table setting most owners have never opened. A Base44 app sends its requests through Base44 instead, so there is no address on the street for anyone to try.
The measurement is lopsided enough to settle it. 1,466 of the 5,442 Base44 apps we graded name a Supabase project somewhere in the page. Our row-level-security check got a usable answer from 2 of them. On Lovable, where the database answers the street directly, 3,553 of 6,535 answered. On Bolt, 35 of 267.
Two apps is not a rate and we are not going to print one. What the number settles is who can look: on a Base44 app the data permission rules are readable from the Security page in your own dashboard and from nowhere else. The full census of what 5,442 Base44 apps scored has the rest of the figures.
Why your published app can still be carrying a key
Because the scan reads your project and your visitors download a file. Four things in Base44's own documentation separate those two:
- The published version can be older than the one the scan read. Base44's credit-protection finding has a state for exactly this, and the issue reads "Publish changes before protecting credits" when your live app is still running an earlier version.
- The status at publish is a warning. Risks found opens the Security page, and you can publish anyway.
- An issue you ignore does not come back. Ignored findings move to their own section at the bottom of the list and, in Base44's words, do not reappear the next time you scan. A clean list can mean somebody dismissed the finding in June.
- The code half needs a paid plan. Code vulnerability scanning runs on Builder and above, as does the optional Wiz integration, which adds static analysis using your own Wiz tenant.
From the pavement, that gap has a size. Of the 5,442 Base44 apps we graded, 95 were serving a Google API key in the page, 11 had something shaped like a password or a token, one had a Stripe restricted key and one a Stripe secret key. The secrets check answered on all 5,442 apps, so those are counts rather than a sample.
That 95 is a smaller share than the neighbours, and worth saying plainly: in the same sweep, 727 of 18,563 Lovable apps and 200 of 3,050 Replit ones carried a Google API key. On this measurement Base44 apps are quieter than the apps built next door.
It is also the finding on this list most likely to be fine. Google issues one kind of API key and expects it in the browser; what decides whether a stranger can run up a bill on it is whether you restricted it to your own domain, and that restriction lives in the Google console, not in your app. What to check on a Google key you found in your own page is the two settings to read.
If you would rather see the whole list of what your published Base44 app hands out, our free scan reads your live address and reports what it can see from outside. It takes about 20 seconds and needs no account: scan your app free.
The check on that list nobody expects
Someone calling your app's paid features directly, without going through your app at all.
Base44 calls this credit protection, and the finding appears when a feature of yours that uses AI, image generation or email can be reached from outside your app. Their documentation is blunt about the consequence: somebody who finds it can run it and spend your integration credits. It is rated High, and depending on your app the fix is either a single Fix button that restricts those features while leaving your own access alone, or a Resolve with AI that moves the calls into your backend.
This is the kind of thing an inside scan is good at and an outside scan has no honest way to test. Finding out whether somebody can run your email feature for free would mean running it, so our scan leaves that one to Base44 and reports what it can read without spending anything of yours.
What neither scan checks
Three things, and the last one is the only item on this page that cannot be repaired afterwards.
Your certificate and your domain, if the app is on your own address. A
Base44 app on a base44.app address inherits Base44's. Move it to a domain you
bought and the renewal dates become yours, which is
the quietest way a working app goes dark.
Files in a Supabase Storage bucket you connected. Of the 1,466 Base44 apps naming a Supabase project, our bucket check could answer on 5. The same wall that hides the database hides the bucket, and Base44's data permission check covers the tables it manages rather than a bucket in a project you attached yourself.
Whether a copy of your data exists. No scan on either side of the wall checks that, because it is not a property of your app. It is a property of what you set up somewhere else, and it decides whether a bad migration or an agent with database access ends in a restore or in an email to your users. The day an AI agent deleted a production database is what the second one reads like.
Keeping both halves covered after you publish
Run both again after anything you change. A result from last week describes last week's app, and on Base44 publishing is one button, so a table added this morning or a key pasted in at midnight is live the moment you press it.
Reeve Monitor runs the nine outside checks again for you:
- all nine checks every hour, on up to three apps
- whether the app is up, every 60 seconds
- a message when a result changes, so a new finding does not wait for you to look
- a monthly report of what it saw
If your Base44 app keeps its data in your own Supabase project, Reeve Care keeps a copy of it:
- an encrypted copy of your Supabase database every night, kept where your project cannot reach it
- each copy verified before it counts, by counting the rows in every table
- a one-click restore when you need one
- your uploaded files as well, once you connect a Storage credential
- everything Monitor does
Both are on the pricing page, which is sometimes below the list figure and never above it.
What to do today
What to do
- Run the scan from Dashboard → Security before your next publish, and read the findings before you press Fix all issues. The unauthenticated-function fix can lock out a page you meant to leave open.
- Check the Ignored section at the bottom of the list. An issue somebody ignored months ago is still ignored today.
- If your app spends integration credits on AI, images or email, read the credit protection finding first. It is the one on the list that costs money by itself.
- Scan the published address from outside afterwards, because the live app can be an earlier version than the one the scan read.
- Keep a copy of your data somewhere your app cannot reach, if you attached your own Supabase project. Nothing in either scan can tell you whether one exists.
Start with the Ignored section, because it takes seconds and it is the one place a clean report can be hiding a real finding. If you want the plain-language version of everything checkable on a Base44 app from outside, we have a walkthrough for Base44 apps.
FAQ
Does Base44 scan my app for security problems?
Yes. Open your app editor, click Dashboard, then Security, then Run Security Scan. It checks seven kinds of problem: data permission rules, exposed secrets, backend functions that answer without checking who is asking, features that spend your integration credits, third-party libraries with known issues, patterns in your own code, and two browser security headers. Each finding comes with a recommended fix you can apply, and the scan never applies one on its own. It is available on every plan, including the free one, though the code half only runs on Builder and above. Read on 10 October 2026.
Is Base44's security scan enough?
It is the only scan that can check the part of a Base44 app that matters most, because your data sits behind Base44 rather than at a public address. What it has no reason to do is fetch your published page and read what went out in it. We graded 5,442 live Base44 apps: the database question was answerable on 2 of them, and 95 were serving a Google API key in the page. Run the inside scan before you publish and an outside one afterwards.
Why can't an outside scanner check my Base44 database?
Because there is nothing on the street to knock on. On most builders your app talks to its database straight from the visitor's browser, so the database has a public address, your page carries it, and anybody can lift it out and ask questions. A Base44 app sends its requests through Base44 instead. Of the 1,466 Base44 apps we graded that name a Supabase project anywhere in the page, our row-level-security check got a usable answer from 2. On Lovable, where the database answers the street directly, 3,553 of 6,535 answered.
What does an outside scan find that Base44 does not?
What your visitors actually receive right now. Base44 reads the project in your editor, and four things in their own documentation separate that from the live app: the published version can be older than the one the scan read, the scan warns at publish without blocking it, an issue you ignore once does not come back, and code-level scanning needs the Builder plan. In the 5,442 Base44 apps we graded, 95 had a Google API key in the page, 11 had something shaped like a password or a token, one had a Stripe restricted key and one a Stripe secret key.
Should I run both?
They answer different halves, so one does not stand in for the other. Run Base44's scan from the Security page before you publish, read the findings before pressing Fix all issues, and then check the published address from outside. An outside scan takes about 20 seconds and needs no account.