Base44 security: what a scan flags, and what is yours to fix

You scanned your Base44 app and the report came back a B, with three amber lines under it: security headers missing, an API open to any website, and your original source code published. Or somebody technical looked for you and said the same three things in a more worried voice. For an app whose code you have never read, the last one lands hardest.

Here is the part that guide after guide about Base44 security gets wrong: nearly every line on that report is about Base44. Three of the four findings that turn up on almost every app are set by the platform, for every app it hosts. And one of the three is a sentence our own scan gets wrong. This post exists because we went back and read what it had found.

Think of your app as a flat in a building Base44 owns. A scan reads the building from the street. The lock on the street door, the sign over it, the rule about who may look through the windows: the landlord decided those, and every flat shares them. What you carried in is a shorter list, and the rest of this post walks the report line by line to say which is which.

What a Base44 security scan finds on almost every app

Three findings on nearly every one, a fourth on about half, and all four decided by Base44.

In August 2026 we ran the same nine checks on 30,998 live vibe-coded apps, 5,438 of them published on Base44. All 5,438 were missing security headers. 5,417 answered a request from a made-up website with a wildcard CORS header. 3,229 of them, 59%, served a source map. 2,705 had an address, named in the app's own code, that answered a request with no login and returned data.

Each percentage is over the apps that check could answer on, which is why the bases differ slightly from the app counts. A check that could not reach an app leaves that app out. It is never counted as clean.

Read the Base44 row against the Lovable row. On Lovable, the first two findings almost never appear, because Lovable's hosting sets both the other way. On Base44 they appear almost every time. A column that uniform across thousands of apps whose owners never spoke to each other is what a platform setting looks like from outside. Nobody chose it in their own app.

The last two columns are decided inside each app, and they tell the other half. A key in the compressed code turned up on 2% of Base44 apps against 4% of Lovable ones, and 2 Base44 apps in 5,438 graded D, against 407 Lovable apps in 18,554. Both of those Base44 apps are in the last section.

The source-map finding on a Base44 app is the badge

Every source map that answered on the Base44 apps we re-opened belonged to Base44's own badge script. None of them held the owner's code.

A source map is a file a build tool writes next to the compressed JavaScript your site ships. It holds the original files, their names and every comment, so that an error can point at the line you wrote instead of at character 48,000 of one enormous line. When the map is published, anyone who presses F12 reads the project as it looked in the editor, and our earlier post covers what that costs on an app where the map is yours.

On Base44 the map is somebody else's. On 16 September 2026 we went back to 30 apps our August scan had flagged and read what each map contained. On 27 of them the only map that answered was /static/js/badge.js.map, the map for the small script that draws Base44's badge on the page, and what it reveals is Base44's code for that badge. On the other 3, no map answered at all. On none of the 30 did a map cover the owner's files. Those files went out compressed and without a map on every app we opened, the first file the page loads and every piece it loads after it.

So the 59% counts something other than published code. Of the 30 flagged apps, 27 of the 28 that answered still carry the badge script in their page, and of 30 apps that were never flagged, 29 do not. The number that reads as "three in five Base44 apps publish their code" is closer to "three in five Base44 apps show the badge".

That leaves a line on our own report to answer for. It reads "Your original source code is published", and on a Base44 app it is true of one file and wrong about your app. The check did what it was built to do: follow the address at the bottom of a script and count a map that answers. Here the script belongs to the landlord. On Lovable, Replit and Bolt the same line means what it says. Of 11 flagged apps we re-opened from those builders, 9 served a map of the owner's own pages and components, and on the other 2 no map answered any more.

What it means for you is that nothing of yours is in that map. The check worth running is the other one: whether anything you pasted into the app is sitting in the compressed file every visitor already gets. That is further down.

Our free scan reads your live Base44 app from outside, all nine checks, in about 20 seconds with no account, and prints "Couldn't check" for anything it could not answer rather than a tick: scan your app.

The CORS wildcard: Base44 sets it, and nothing private answers behind it

You cannot change it, and on the Base44 apps we looked at there is no private data behind it.

The finding is one line in your server's answers, Access-Control-Allow-Origin: *, which tells a visitor's browser that a page on any other website may read this particular answer. Base44's documentation says where it comes from (read 16 September 2026): "Per-app CORS configuration is not currently available. Base44 manages CORS at the platform level." Every app on the platform sends it, which is how 5,417 apps out of 5,419 came to share one finding.

Whether a wildcard matters depends on what answers behind it, and the longer write-up walks through why. The short version: the header arrives after the answer has already been sent, and only a browser reads it, so narrowing it would stop other websites' pages from reading your app and nobody else. What sits behind it on a Base44 app is the app itself, the page, the compressed code, the badge, all of which every visitor downloads anyway.

The fourth finding is where a wildcard would matter. On 2,705 Base44 apps, about half, an address named in the app's code answered a request with no login and returned data. We re-opened 12 of those on 16 September. On six, nothing answered any more. On the other six the address that answered was the same one every time, /api/consent/config, and what it returns is the app's cookie-consent settings: whether a consent banner is on, which region's rules apply, how many months the answer is remembered. It is configuration. Nobody's rows are in it.

Your data does not travel that way on Base44. Your app asks Base44's backend, the backend applies the permission rules you set on each table, and the answer comes back through the same door. A scan from outside cannot see those rules at all, which is why the Base44 guide spends its time on what a stranger can reach, and leaves your rules to you.

What is yours on a Base44 app

A short list, and both D grades in the sweep came from it.

A key you pasted in. 103 of the 5,438 Base44 apps, 2%, shipped something key-shaped in the code every visitor downloads. 95 of those were Google API keys, which usually need a restriction set in Google Cloud, and no rotation. One was a Stripe secret key, and that app graded D. Base44 keeps its own credentials on its server, so a key in your bundle is one you or the builder added for a feature: a map, an analytics tag, a payment form. Which kind it is takes a minute to read, and a secret one is rotated where it was issued before it comes out of the code.

The permission rules on your tables. Base44 calls them data access rules, and they decide who may read and edit each kind of record. Nobody outside can test them, us included, and that is the one place an outside scan has to leave a blank. Base44's own security scan does read them, and its documentation says the scan is available on every plan, including the free one.

Anything you connected yourself. The other D in the sweep was a Base44 app with a Supabase project of its own, and a table in it named like personal data that answered a request with no login. Attach your own database and the usual row-level rules apply in full, because that project answers the internet directly.

What you can change from inside Base44

Two headers, your table rules and your keys. The rest is set for every app on the platform.

Base44's documentation lists what is yours to switch (read 16 September 2026). In your app's dashboard, under Security and then the settings icon, you can turn on two security headers. Prevent Embedding sets X-Frame-Options, which stops your app being shown inside another site's page. Restrict Browser Features sets Permissions-Policy, which limits what your app may ask the browser for, camera and location included. If people sign in to your app and can do something consequential in one click, turn the first one on. The same page says Content-Security-Policy and Strict-Transport-Security "are not configurable at the individual app level". That is most of the headers finding, and it is out of your hands.

Base44's own scan covers the inside: data permission issues, exposed secrets, backend functions with no sign-in check, dependencies and, on the Builder plan and above, code vulnerabilities. Its documentation does not mention source maps or the CORS header, which is fair, because both belong to the platform. An outside scan covers what a visitor's browser is handed, and on a Base44 app that is where the list is shortest.

What to do right now

Publishing on Base44 is one click in the top bar, and nothing between that click and the internet re-reads the app for a key that got pasted in to make a feature work. A scan you ran last month describes last month's app.

Reeve Monitor is built for that. It re-runs all nine checks every hour on up to three apps, watches uptime every 60 seconds, tells you when a result changes rather than waiting for you to look, and sends a monthly report. It is $12 a month at list, with seven days free before it charges you; the pricing page is sometimes below the figure here and never above it. Monitor watches and nothing more, which for a Base44 app is the half that fits: Care, our backup plan, backs up Supabase projects only, and a Base44 app keeps its data inside Base44 unless you attached a project of your own.

The plain-language walkthrough for this platform is is your Base44 app safe, and the 10-minute security checklist covers what is worth confirming on any newly launched app, whatever built it.