FOR PEOPLE SHIPPING BASE44 APPS

What Base44 apps get wrong

In round 2026-09 of the Vibe Security Index we scanned 50 public repositories carrying Base44's scaffold marker with all 212 rules. These are the security findings that repeated, why this particular workflow produces them, and the prompt change that prevents each one.

Read this first

→This is not a claim that Base44's product is insecure. We measured public repositories carrying its scaffold marker (@base44/sdk in package.json), edited by humans for an unknown period afterwards. The marker proves the project started from the scaffold. It does not prove any particular line was generated rather than written, and attributing a finding to the builder is not something this design supports.
→50 repositories, drawn from a universe of 1,760. Every rate on this page is stated with the count behind it, because a percentage over 50 is a different kind of object than a percentage over 1,760: the finest distinction 50 repositories can draw is one repository. Differences of a few points here are noise.
→The enforcement this platform relies on is not in the repository. Base44 apps talk to a hosted backend, and the permission rules that actually protect the data are configured there rather than committed to the project. A code scan cannot see them. That shapes several findings below, and each one says so rather than letting you assume the scan covered it.
→No repository is ever named. Not here, not on the Index, not in the working data. Publishing the list would mean pointing at live vulnerabilities in other people's projects, so the results are aggregate only and the per-repository rows are anonymised by design.
→Static analysis has false positives, including ours. A finding is something a person should look at, not a proven breach. Where a finding on this list is partly our own noise, it says so directly underneath.

Round 2026-09, generated September 3, 2026. Full method, sampling frame and limitations: Index methodology.

The shape of the sample

42%

had at least one critical finding in their own code

21 of 50

98%

had at least one high or worse

49 of 50

median findings per project, application code only

across 50 projects

84.5

median scanned files per project

size is a confound on every rate above

Why the loudest findings are not on this page

Sorted by raw occurrence count, the top of this builder's results is code quality, not security. Magic Numbers in Code (344 occurrences across 45 of 50 projects), N+1 Query Pattern Detected (99 occurrences across 17 of 50 projects) and Console.log Left in Production Code (98 occurrences across 27 of 50 projects) are all info severity, a call this codebase made deliberately and has not changed. They are worth cleaning up. They are not what someone shipping an app to real users is asking about, and a security page that led with them would be counting lines instead of answering the question.

So the list below is filtered by severity and then ordered by severity, with how many projects a finding appeared in as the tiebreaker. Occurrence count never decides the order — one finding here fired hundreds of times inside half the sample, and letting that sort the page would have put an information leak above an authorization decision. There is a second filter on top of that one. The finding at the very top of the severity sort is a missing response header, which is present in every project and describes where the app is hosted rather than the code in it. So the page leads with the most severe finding that is actually in the repository: Unvalidated Redirect, in 19 of 50 projects. The header cluster still gets its own section, at the end.

Security findings that repeat, application code only

From round 2026-09. n = 50 repositories. “Projects” is how many of them contained the finding at least once; occurrences is the total across all of them.

Finding	Severity	Projects	Occurrences
Missing Content Security Policy (CSP)VC020	high	78%39 of 50	57
Unvalidated RedirectVC016	high	38%19 of 50	48
Client-Side Only AuthorizationVC010	high	32%16 of 50	32
API Route Missing AuthenticationVC003	high	30%15 of 50	193
Clickjacking — Missing X-Frame-OptionsVC056	medium	80%40 of 50	66
Missing Security Meta Tags / HeadersVC027	medium	78%39 of 50	113
Timing-Unsafe Secret ComparisonVC043	medium	32%16 of 50	48

This is the round's top-rules list with info and low severity removed. It is not the complete finding list for any project, and a check that never made this builder's top ten can still be the one that matters in yours. API Route Missing Authentication, Timing-Unsafe Secret Comparison appear in the table without a section below — real, but less specific to this workflow than the rest.

Each one, and what stops it coming back

Fixing the finding fixes one line. Changing the instruction that produced it fixes every line the next prompt writes, which is the only version of this that scales when the code is arriving faster than it can be read.

highVC016 · 19 of 50 projects · 48 occurrences

Navigation that goes wherever it is told

Unvalidated Redirect

Why this workflow produces it

Read the two numbers in the header of this section together: it reached most of the sample and fired several times inside each project. That is not one login redirect. That is a navigation pattern used throughout the app.

These projects are single-page dashboards, and the generated navigation helper takes its destination from something dynamic — a query parameter, a stored return-to value, a field on a record — and hands it to the router or straight to the browser's location.

The behaviour it implements is genuinely useful, which is why it never gets removed: send the user back where they came from after signing in, or forward to the thing they clicked before they were asked to authenticate. The only missing piece is that the destination is never checked against the set of places you are willing to send somebody.

The result is a link on your own domain that quietly bounces a visitor onto someone else's, carrying your app's credibility with it. On a page people reach while signed in, that is a working phishing setup that costs the attacker nothing to build.

The change that prevents it

Resolve destinations against an allowlist of your own routes instead of passing a URL through. A redirect parameter should name a route, not supply a location.

Paste this into your project instructions, or into the prompt itself:

Never pass a value from a query string, a stored value or a
record field directly to router.push, navigate or
window.location. Redirect targets must be looked up in an
allowlist of internal route names defined in code. If a
value does not match one, fall back to the home route
rather than following it.

The scan that verifies it

Scan, then try it: load your own app with a redirect parameter pointing at an external domain and see whether it follows. That single test answers the question faster than reading every hit.

npx xploitscan scan . -f json \
  | jq '[.findings[] | select(.rule == "VC016")] | length'

Honest caveat. This check cannot always tell an internal route constant from a value someone else controls, so expect a share of these to be internal navigation that was never a risk. It is also worth being accurate about the impact — in a client-side router this is a phishing and trust problem, not a server-side request forgery. Worth an hour, not a weekend.

highVC010 · 16 of 50 projects · 32 occurrences

Permission checks that live in the browser

Client-Side Only Authorization

Why this workflow produces it

This is the finding that is really about this builder, and it follows directly from how the platform works. A Base44 project talks to a hosted backend through an SDK that runs in the browser, so for most of these projects the entire application is client code. There is no server file in the repository to put a check in.

So a role test — show the admin panel to admins, hide the delete button from a viewer — gets written where the app actually is: inside a React component. As a user-interface decision that is completely correct, and the app behaves properly for every user who is not trying anything.

It stops being a security control the moment someone opens developer tools. The component tree, the role variable and the conditional are all in code that was shipped to the visitor, and the same session that renders the page can call the SDK directly from a console. Hiding a button does not stop the operation behind it.

The control that does stop it lives in the platform's own permission configuration, and that is not in the repository at all. Nothing in the codebase reminds you it exists, and a scan of the codebase cannot confirm you have set it.

The change that prevents it

Treat every role test in the client as presentation, and pair each one with a rule enforced on the data itself in the backend's permission settings. The prompt change is to require the pairing out loud, so the generated component and the backend rule get designed together rather than one of them being assumed.

Paste this into your project instructions, or into the prompt itself:

Treat every role or permission check in React as
presentation only. For each one, name the matching
server-side rule that restricts the same data in the
backend's entity permissions, and set it there. Never let a
hidden component, a disabled button or a client-side route
guard be the only thing keeping a user out of another
user's records.

The scan that verifies it

Scan to get the list, then use it as an inventory: for each hit, name the backend rule that enforces the same restriction. Then check it for real — sign in as your lowest-privilege test user and call the data operation directly from the browser console. If it returns records that user should not see, the check was decorative.

npx xploitscan scan . -f json \
  | jq '[.findings[] | select(.rule == "VC010")] | length'

Honest caveat. Be clear about what this rule can and cannot tell you here. It reads your repository, and on this platform the enforcement lives outside it — so a project with perfectly configured backend permissions will still report every one of these hits, and a clean result on this check is not really achievable. A hit is not evidence of a hole. What the list is genuinely good for is enumerating every place your app makes an authorization decision, so you can confirm each one has a server-side twin.

highVC020 · 39 of 50 projects · 57 occurrences

The response headers a static host does not set for you

Missing Content Security Policy (CSP)

Why this workflow produces it

This is really three findings in the table above — the missing content-security policy, the missing frame-ancestors control, and the missing content-type and referrer policies. They travel together because they have one cause.

A Base44 project ships as a static bundle served by a host. All of these are response headers, and a static file does not carry a response header. Something in front of it has to add them, and the default deployment target usually adds none.

Nothing looks broken as a result, because none of these headers change how a working app behaves. They only change what happens during an attack, which is why they survive every round of testing you do before launch.

The change that prevents it

Add them where the host reads them: a _headers file on Netlify or Cloudflare Pages, the headers array in vercel.json on Vercel. The content-security policy is the one worth real time and the one most likely to break something, so run it in report-only mode first and read the reports before you enforce it. The rest are close to free.

The scan that verifies it

Scan for all three, then check the live response and confirm the headers actually arrive: curl -sI https://your-app.example. The scan reads your repository; only the response proves a header is really being sent.

npx xploitscan scan . -f json \
  | jq '[.findings[] | select(.rule == "VC020" or .rule == "VC027" or .rule == "VC056")] | length'

VC027 and VC056 are outside the free rule set. The free scan runs 30 of the 212 rules, so a free plan never evaluates them. This command also counts VC020, which a free scan does run — so the number it returns on a free plan is the VC020 count alone, and it says nothing either way about VC027 and VC056.

Honest caveat. This cluster fired on every project in the sample, which says more about the scaffold than about any developer — and part of it is a measurement limit on our side. The scanner reads your repository, so a host that already injects these headers still reads as missing. Check the live response before you spend an afternoon on it.

The one we are still bad at, stated plainly

Everything above is a finding we detect well. This section is the opposite: a separate research pass over the same sampling frame went looking for request handlers with no authentication check, and the honest result is that our shipped rules flag well under half of them in Base44-shaped code.

118

handlers in the Base44 slice where the analysis could find no authentication check

39%

of those 118 that our shipped rules flag today — a point estimate, not the middle of the interval below

95% confidence interval 31%–48%

The count on the left is worth a second look on this builder in particular. A platform whose whole premise is a hosted backend might be expected to have almost no server code of its own in these repositories, and 118 handlers says otherwise: a meaningful share of these projects add their own server functions or routes alongside the SDK. Those are the parts of a Base44 app where the platform's permission model is not protecting you, and they are also the parts our rules currently miss most of.

This is not a builder ranking. The research pass behind these figures states in its own limitations that it does not support comparing one builder against another, so this page reports its own slice and nothing relative to anyone else's.

For context from the same pass, across all four builders and 174 repositories: 51% [44%–58%] had any server-side handler at all, and of those, 69% [58%–77%] had at least one handler with no authentication check the analysis could find. Those two figures are round-level, not Base44-specific, and are labelled that way on purpose — the research pass does not break them out per builder, so neither does this page.

What that does not mean

•A shape is not a vulnerability. Nothing was exploited and no request was ever sent to a running application. A handler in this class is one where a static pass could not find an auth check. Some fraction are protected by means the method cannot see.
•47.5% of handlers were undecidable from a single file and were classified as such rather than guessed at. A handler goes to that bucket whenever protection might exist somewhere the analysis cannot look — middleware mounted before the route table, for instance. Every rate above excludes them, so these describe the decidable slice, not the whole corpus.
•The related ownership check is not settled enough to quote. The pass also looked for handlers that authenticate the caller but never scope the record to them. In the Base44 slice that class measured 2 handlers under the strict definition and 10 under the loose one. A class whose size moves fivefold with where you draw the line is not a number we are willing to headline, so it is here as a range and nowhere else.
•Handler counts are concentrated. A handful of large repositories contribute most of the handlers, so a handler-level percentage is closer to a statement about those projects than about a typical one.

We publish this because a scanner that only advertises what it catches is not much use for deciding whether to trust it. If your project has server-side functions alongside the SDK, read them yourself with one question in mind: who is this endpoint willing to answer? Our benchmark page carries the same disclosure in the other direction — a held-out access-control case that no scanner we test catches, including ours.

The findings we do not count against you

Every number above covers application code only. A Base44 project also arrives with a copied-in component library, and findings there are separated before any headline figure is computed. They are reported, never hidden, and they never touch a grade.

In this round 30% of the 50 projects (15 of 50) had a critical finding in that copied-in code — a higher rate than the 42% in their own code. That column is mostly our false positive. One component in the suite sets CSS variables through a raw-HTML style block, which trips a critical cross-site-scripting rule. It is CSS-variable theming, not an injection sink, and a rule that flags it is our bug rather than yours or the builder's.

Because that one file is byte-identical everywhere it is copied, it shows up in almost every project that vendors the suite. Reading it as a security signal would mean ranking projects by how much of a component library they happened to copy in. This is also why your grade is computed on your own code by default — you can opt into the stricter view with xploitscan scan . --grade-vendored if you want everything counted.

Find out which of these are in your project

Same application-versus-scaffold split, run against your repository instead of someone else's. No credit card and no signup for the first scan — that one runs the 30 free rules rather than the 212 this round used, and the full set comes with a paid plan.

Run a scan — no signup See round 2026-09 in full

Numbers on this page are read from the published Vibe Security Index round 2026-09 at build time. Method and limitations: methodology.