Reeve Is your Base44 app safe?
Base44 keeps your database off the internet, which removes the biggest risk in vibe-coded apps. What is left is a short list, and it is almost the same list on every Base44 app.
Logos are the property of their respective owners, shown to indicate compatibility.
In short
- Base44 does not expose your database to the internet. The mistake that leaks most vibe-coded apps is not available to you, and that is a real advantage.
- The risk moves to what the browser can see: an API that answers any website, and your original code published beside the app. Those two are on nearly every Base44 app we scan.
- Nobody can check a Base44 database from outside, us included. If you attached your own Supabase project, that part is checkable and worth checking.
Base44 does something the other builders do not, and it is worth knowing before you go looking for problems: your data never answers the internet directly.
Your app asks Base44 for something, Base44 asks the database, and the answer comes back the same way. There is no address a stranger can type. On most vibe-coded apps the single biggest cause of leaked data is a table left readable to anyone holding the project address, and on Base44 that mistake is not really available to you.
Here is the part that guide after guide gets wrong: that does not make your app safe, it makes it safe in one specific way. The risk moves, and where it moves is predictable enough that we can tell you now, before you scan anything.
What Base44 keeps off the internet for you
The stockroom, to use the obvious comparison.
Think of your app as a shop. Everything a visitor's browser downloads is the shopfront and it is handed over in full to anyone who loads the page: a browser cannot display something it was not sent. Behind that is the stockroom, your data. On most builders the stockroom is a separate building with its own address on the same street, and whether strangers can walk in depends on a setting you may never have seen. On Base44 there is no street door.
In practice that means there is nothing to paste into a browser. On a Supabase-backed app anyone can lift the project address out of your bundle, add a table name, and see what comes back. Do the same on a Base44 app and the only address you find is your own, on your own domain, answering the things your app was written to answer.
It shows up in the grades. Across the Base44 apps in our scan of live vibe-coded apps, almost every one lands an A or a B, and the failures that pull other builders down to a D barely appear.
It also has one honest consequence, which is that nobody outside can verify it, including us. A check from the internet can only try doors that exist. There is no door here, so there is nothing to report, and a scanner that printed "database: secure" on that basis would be inventing a result.
Is a key in your Base44 app a problem?
Usually not, and the two kinds look nearly identical.
A publishable key names a project and does nothing else. It is meant to be
readable, and finding one is not a finding. A secret key, the kind spelled
sb_secret_…, service_role or sk_live_…, bypasses every rule you have
written and can read and change everything.
Base44 keeps its own credentials on the server, so a key sitting in your app is usually not Base44's at all. It is from something you connected yourself: a maps key, an analytics key, a payment key pasted in to get one feature working. The most common one we find on Base44 apps is a Google API key, which is worth understanding rather than panicking about because an unrestricted one can be spent by strangers. Reading which key you have takes about a minute.
If you do find a real secret, the order matters. Rotate it where it was issued, in Google Cloud or Stripe or wherever it came from, and take it out of your code after that. Deleting the line first closes nothing: the old value is already in every cached copy of your site and in whatever a crawler saved last week.
The setting that is wrong on almost every Base44 app
Not a key, and not the database. It is who your API is willing to talk to.
A browser normally refuses to let one website read another website's data. That
rule is why a page you open cannot quietly call your bank and put your balance
on screen. A response header called CORS is what waives it, and set to * it
waives the rule for everybody, so a site you have never heard of can call your
app's API from your visitor's browser and read what comes back.
On the Base44 apps we have scanned this is the most common finding by a distance. It is also the one people argue with, and the argument is fair, so here is the honest version. A wildcard in front of an address that demands a login is weak news, because the other site still has no credentials to send. A wildcard in front of an address that answers anybody is the real thing, and about half the Base44 apps we scanned have at least one address that hands back data to a plain request with nobody signed in. Those are two different problems wearing one label, and the second is the one to go looking for.
Neither is a mistake you made. A wildcard is what a build tool ships when nobody told it otherwise, usually so a preview domain and a live domain both work while you are building. The short write-up has the fix, which is naming your own domain in place of the star.
Your original code, published beside the app
The second most common finding, and the one you can check without any tools at all.
A source map is a file that turns the compressed JavaScript a browser runs back into what you wrote, with the original filenames, the comments and the folder structure intact. Build tools generate them so an error in production points at a real line instead of at column 4,812 of one enormous file. That part is genuinely useful. Publishing them next to the app is the part that costs you.
Roughly three in five Base44 apps we scanned ship theirs. No data leaks because of it, and nothing about your app behaves differently, which is exactly why it goes unnoticed for months. What changes is the effort in everything else: picking an endpoint out of a minified bundle is slow, fiddly work, and reading your own source is no work at all. Every other finding on this page gets cheaper to find once your code is legible.
Checking takes under a minute. Open your live app, press F12, and look at the Sources panel. If the file tree there looks like your project, with the names you gave things, the maps went out with the build, and the longer version covers what to change.
If you plugged in your own database
Then the advantage at the top of this page does not apply to that part, and the usual rules come back.
Roughly a quarter of the Base44 apps we scan name a Supabase project of their own. That project answers the internet directly, exactly like every other builder's, so Row Level Security is now yours: a per-table switch deciding row by row who may read what.
Two things decide whether you have it. Supabase enables it by default for tables created in the dashboard's Table Editor, and not for tables created by running SQL, which is how most generated setups create them. And the switch is only half of it, because a policy that permits everyone leaves the table open while the dashboard reports it as secured.
Storage works the same way and is easy to forget, because it lives in a different part of the dashboard from the table rules. A bucket marked public can be listed and downloaded by anyone who knows it is there, whether or not your app ever links to a file in it, and the settings that decide that are worth reading once.
How to check your own Base44 app in about ten minutes
Ask what your API tells other sites. This is the one most likely to be wrong and the one nobody looks at, because nothing in your app misbehaves when it is set too widely.
Open your live app with F12 and read the Sources panel. If your own files are listed there under their own names, everyone else can list them too.
Read any key in the app. For each, ask whether you would put it on your homepage. If the answer is no, it belongs on a server, and it needs rotating at the source before it comes out of the code.
Open Authentication → Policies, if you attached your own Supabase project. Any table listed with Row Level Security disabled answers anyone holding the project address, and that address is in your app.
Then look from outside. The steps above tell you what is configured. What a stranger can actually reach is a different question, and it is the one our free scan answers. It reads your live site as a visitor and gives you a grade in about 20 seconds, no account: scan your app.
What to do
- Base44 keeps your database off the internet. The biggest cause of leaked data in vibe-coded apps is not available to you.
- Nobody can verify that from outside, us included. No door means no result, and no result is not a green tick.
- The risk moves to the browser: an API that answers any website, and your source code published beside the app.
- A wildcard in front of an address that needs no login is the version that matters, and about half of these apps have one.
- A key in your bundle is usually from a service you connected yourself. Rotate it where it was issued, then delete it from the code.
- Attach your own Supabase project and the usual Row Level Security and storage rules apply to it in full.
Start with the two that are almost always worth fixing: what your API tells other websites, and whether your original code shipped with the app. Then the 10-minute security checklist covers the rest.
What can actually go wrong with a Base44 app
These are ordered by how often we actually see them on Base44 apps, which is not the order you would guess. Nothing here means you did something wrong.
Your API answers any website that asks
This is the common one on Base44, by a distance. A browser will normally refuse to let one site read another site's data, and a setting called CORS is what waives that rule. Set to "*", it waives it for everybody, so a page you have never heard of can call your app's API from a visitor's browser. Reeve checks what your app tells browsers here.
Your original code shipped with the app
A source map is a readable copy of the code you wrote, published beside the version the browser runs. Handy while you are building, and a gift to a stranger once you are live: it turns "poke at a minified bundle" into "read the app". It does not leak data by itself. It makes everything else easier to find.
Missing browser safety headers
A handful of response headers tell a browser how to protect your visitors: do not guess file types, do not let another site frame this page, do not leak the full address on the way out. They are small individually. Together they decide how much someone can do with anything else they find.
A key from something you connected yourself
Base44 holds its own credentials server-side, so the keys that show up are usually from a service you wired in: a maps key, an analytics key, a payment key pasted in to get a feature working. Some keys belong in a browser and are fine. Reeve reads your app's loaded code, finds any keys, and tells you which are which without ever storing the real values.
A database you connected yourself
If you attached your own Supabase project rather than using Base44's built-in data, you also took on its rules. Row Level Security decides who may read each row, and it is off by default for tables made by running SQL. That is the one path where the usual open-database problem does reach a Base44 app. Reeve checks by counting rows, never by reading them.
Files anyone can list
Uploads land in storage buckets, and a public bucket lets anyone list and download what is inside: invoices, IDs, private photos. Reeve checks whether your buckets are listable. It never downloads anyone's files.
What Reeve is, and what it isn't
Reeve is a free, read-only check from the outside, like an inspector trying the doors without going in. It catches the common, high-impact mistakes fast. It is not a full security audit, and a clean grade is not a guarantee; it means the obvious doors are shut.
Base44 apps grade better than most, and that is a real result rather than a compliment: the platform holds the part that usually goes wrong. What is left is a short and fairly uniform list, which is good news, because a short list is one you can finish. And if you would rather the watching was not your job, make it ours.
Want it handled, not just checked?
Reeve Care keeps watching your app, backs up your data, and helps you fix what breaks, so you can keep building instead of worrying.
Learn about Reeve CareFAQ
Is a Base44 app safer than one built somewhere else?
On one specific thing, yes. Your database is not reachable from the internet, so you cannot make the mistake that exposes most vibe-coded apps: a table left readable to anyone with the address. That is the single biggest cause of leaked data in apps like yours, and Base44 takes it off your plate. Everything a browser can see is still yours to get right.
Can Reeve check my Base44 database?
No, and neither can anyone else from outside. Your data goes through Base44's own backend rather than answering the internet directly, so there is no door for a check to try. We say so on our research page too, and we would rather tell you that than print a green tick we did not earn. If you connected your own Supabase project, that part we can check.
My app has an API key in it. Is that a problem?
It depends entirely on which key. Some are designed to be public and your app cannot work without them; others hand over an account. Base44 keeps its own credentials on the server, so a key in your bundle is usually from a service you connected yourself. Reeve reads the key type and tells you which one you have, in words, without storing the value.
Will scanning my Base44 app change anything?
No. Reeve only looks at what is already public from the outside. It never logs in, never changes anything, and never downloads your files. Read-only, like checking whether a door is locked without stepping inside.
If my database is not reachable, is there anything left to worry about?
Yes, but a shorter list than most people have. Your app still runs in a browser, and everything the browser receives is public: the code, any keys built into it, and the addresses it calls. The two things worth checking are whether those addresses answer requests from other websites, and whether a readable copy of your source went out with the build.
If nobody can check it from outside, how do I know my data is fine?
From inside, which is the only place that answer exists. Because requests go through Base44 rather than to a public address, whatever decides who may read what lives in your app and in the platform, where a stranger cannot probe it. So the useful questions are who can sign up, what a signed-up person can see, and whether any screen was built assuming nobody would look. An outside scan answers none of those. It answers the other half: what somebody reaches without signing up at all.
My scan says my API answers any website. Did I do that?
Almost certainly not on purpose. A wildcard is what a build tool ships when nobody told it otherwise, usually so that a preview address and a live address both work while you are building, and it survives into production because nothing in your app breaks when it is too wide. What decides how much it matters is whether the address behind it needs a login. One that answers anybody is the version to fix this week.
I connected my own Supabase project to my Base44 app. Does that change things?
It changes the most important thing. Your own project answers the internet directly, so the per-table Row Level Security setting is now yours to get right, and it is off by default for any table created by running SQL. That is the one path where the classic open-database problem reaches a Base44 app, and it is worth ten minutes of your time.