SCAN YOUR BASE44 APP FOR VULNERABILITIES

Base44 turns a prompt into a hosted app in one session — it generates entities (its name for database collections), pages, actions, and integrations, and deploys them to a live URL. The platform handles HTTPS, account isolation, and managed deploys correctly. The gap is consistently application-level: the AI ships functionality faster than it ships hardening, and the app that works in the builder is the same app on the public internet the moment it deploys.

Two Base44-specific defaults drive most of what we find. First, entity permissions default to permissive — many templates create entities any authenticated user can read and write, which is fine for a demo and catastrophic for real multi-tenant data. Second, entity IDs are often short and predictable, so even a correctly-scoped permission can be defeated by enumeration. On top of that, generated actions can be publicly callable, and integration keys sometimes land in client-visible code.

A black-box scan against the deployed URL is what surfaces these. It signs in as one user, tries to reach another user’s records, enumerates entity IDs, calls actions without auth, and reads the shipped bundle for keys — none of which is visible from inside the Base44 editor.

Common vulnerabilities we find in Base44 apps

Over-permissive entity permissions

The default entity permission is often “any authenticated user can read and write.” An Orders entity left at that default lets any signed-in user iterate records and dump every order, including addresses and masked card data. This is the recurring shape. Scope each entity’s read to “owner or admin” and write to “owner” — “authenticated” alone is not a scope. Add an explicit members field for genuinely shared data.

BOLA via predictable entity IDs

Base44 entity IDs tend to be sequential or short, so even when a permission is correct an attacker can enumerate IDs and watch which return 200 versus 403 to map the dataset. Combined with a permissive entity, they read records the rule was meant to hide. The test is direct:

# as user B, refetch an ID that belongs to user A
GET /api/entities/Order/1042   ->  must be 403 or 404, never 200

Confirm permissions deny by default and expose a UUID external_id in URLs instead of the sequence position. See BOLA in AI-generated CRUD.

Publicly callable actions and dashboards

Generated actions that return or mutate data frequently ship without an auth gate, and Base44’s public-share links for dashboards are often left on by default. A public dashboard that aggregates over an entity leaks counts, names, and sample records to anyone with the URL; a public action is a direct data path. Confirm every data-returning action requires auth, and switch dashboards to authenticated access unless the data is genuinely public.

Integration keys in client-visible code

Base44’s Integrations tab holds API keys platform-side, but it is easy to call an integration from a client-side action that exposes the key, or to paste a key into a custom code block. Open every custom code block and page action and confirm keys are referenced through the Integrations API, never as string literals; check the deployed bundle for sk_, re_, sk-proj-, AIza. Move all third-party calls to server-side actions. The Token Leak Checker catches what leaked.

File uploads that accept anything

Base44 file fields accept any MIME type by default. A user who uploads evil.html or an SVG containing <script> gets it served from your domain as same-origin script — stored XSS. Allowlist MIME types per field, force Content-Disposition: attachment on user uploads (or serve from a cookieless subdomain), and cap file size. See file upload handling.

Surviving admin bypasses and demo data

Base44 templates ship testing shortcuts — a /dev-login page, a hardcoded admin@example.com / password, a “skip auth” toggle gated on DEV === true. Promoted to production, these frequently survive. Search pages and integrations for dev_login, hardcoded passwords, and dev-only gates, remove the bypass entirely, and delete seed users before launch.

How VibeEval works with Base44

1. Enter your deployed Base44 URL. Optionally provide two test logins so the agent can run cross-user checks.
2. The agent drives a real browser through the app. It maps entities and actions, signs in as one user and tries to read another’s records, enumerates predictable IDs, calls actions with no auth, probes public dashboards and share links, and reads the bundle for leaked integration keys.
3. You get a report of findings by severity, each with the evidence (the entity that answered for another user, the ID that enumerated, the action that ran unauthenticated) and a paste-ready fix — the permission scope, the auth gate — you can apply in Base44.

Manual testing vs VibeEval

Manual review still owns the access model — which role should see which entity and why. The scanner wins on repeatability: when Base44 regenerates, entity permissions can silently revert to the default, so the check that counts is the cross-user pass you can rerun in full after each change.

Frequently asked questions

Does VibeEval understand Base44’s entity model?

The scanner tests the deployed app as an attacker would — enumerating IDs, replaying requests across users, calling actions without auth — which is exactly how permissive entity permissions and predictable IDs get exploited. It reports findings against the URLs and actions your app exposes.

Can I scan during Base44 development?

Deploy to a staging URL and scan there. Production behavior — real auth, real share-link settings, the real bundle — differs from the builder preview, which runs as you with data you own.

What are the most common Base44 findings?

Over-permissive entities readable across users, BOLA via predictable IDs, publicly callable actions or share-linked dashboards, and integration keys in client-visible code. All four are configuration and code-level fixes, not platform bugs.

Will scanning affect my app?

No. VibeEval probes are non-destructive — it reads and replays requests but never modifies or deletes your data.

Related Base44 resources

• How to Secure Base44 — full hardening guide, entity permissions to integrations.
• Is Base44 Safe? — the six areas to harden in every Base44 app.
• Base44 Security Checklist — pre-launch checklist, critical-first.
• Token Leak Checker — find integration keys in the deployed bundle.
• BOLA in AI-Generated CRUD — predictable IDs and ownership checks in depth.

Test your Base44 app before launch

Base44 gets you from prompt to a shared app fast — and the permissive entity defaults ship with it. Scan the deployed URL before you invite users: cross-user access, ID enumeration, unauthenticated actions, and leaked keys, in one pass.