BASE44 SECURITY CHECKLIST

Base44 is an AI app builder that generates entities (its name for database collections), pages, and integrations from natural language. The most common security issues come from two patterns: the default permission model on entities is “any signed-in user can read everything”, and the entity IDs are sequential or predictable, so even when a permission is correct, attackers can enumerate the records the rule was supposed to hide. The checklist below is what we look for first when we audit a Base44 app.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once in the Base44 admin panel and a second logged-in user account, ticking items as you go. After each fix, sign in as user B and try to read user A’s data. After the whole list passes, run a black-box scan against the deployed URL.

Critical (fix before launch)

1. Lock down entity permissions per role

Why it matters. Base44’s default entity permission is too permissive for production: most templates create entities that any authenticated user can read and write. That’s fine for a demo, catastrophic for a real app where users shouldn’t see each other’s data.

How to check. In the Base44 dashboard, open every entity and inspect its permissions tab. For each, confirm read/write are scoped by created_by == current_user or by an explicit role. “Authenticated” alone is not a scope.

How to fix. Set per-entity permissions: read = “owner or admin”, write = “owner”. For shared data, add an explicit members field and scope reads to it.

2. Remove built-in admin auth bypass before going live

Why it matters. Base44 templates ship with an “admin login” shortcut for testing — a hardcoded email/password or a “skip auth” toggle in dev mode. Templates that get promoted to production frequently keep the bypass.

How to check. Search your app’s pages and integrations for admin@base44, dev_login, hardcoded passwords, or pages gated only on process.env.DEV === true.

How to fix. Remove the bypass entirely. Run real admin auth through the same flow as user auth, gated by a role attribute on the user entity.

3. Validate every API integration for credential exposure

Why it matters. Base44’s “Integrations” tab wires up Stripe, Resend, Slack, OpenAI, etc. by holding the API key on the platform side — but it’s easy to accidentally call those integrations from a client-side action that exposes the key to the browser, or to embed the key in a custom code block.

How to check. Open every custom code block and every page action. Confirm API keys are referenced via Base44’s Integrations API, not pasted as string literals. Check the deployed app’s bundle for known key prefixes (sk_, re_, sk-proj-).

How to fix. Move all third-party API calls to server-side actions. Reference keys via Base44’s secure integration store, never hardcode.

4. Audit business logic for IDOR — entity IDs are predictable

Why it matters. Base44 entity IDs are often short and sequential. Even when permissions are correctly scoped, an attacker can enumerate IDs and watch which return 200 vs 403 to map your entire dataset. Combined with overly broad permissions (item 1), they can read records they shouldn’t.

How to check. Sign in as user A, note an entity’s ID, sign in as user B, and try to fetch the same ID. The response must be 403 or 404, not 200.

How to fix. Confirm permissions deny by default. Consider adding a UUID external_id field for IDs exposed in URLs. Avoid leaking sequence positions in URLs.

5. Disable public dashboards that expose internal data

Why it matters. Base44 supports public-share links for dashboards. Templates frequently set them on by default for “easy sharing”. A public dashboard that aggregates over an entity can leak counts, names, or sample records to anyone with the URL.

How to check. Audit every dashboard and report. Confirm “Public access” is off unless the data is genuinely public.

How to fix. Switch to authenticated access. For genuinely public dashboards, scope the underlying query to public-safe columns only.

6. Verify file upload entities reject dangerous types

Why it matters. Base44 file fields accept any MIME type by default. Without an allowlist, users can upload HTML files that get served from your domain and execute as same-origin scripts.

How to check. Try uploading evil.html and evil.svg containing a <script> tag. If the file URL serves them with text/html or image/svg+xml, you have a stored XSS.

How to fix. Allowlist MIME types per file field. Force Content-Disposition: attachment on user-uploaded files, or serve them from a cookieless subdomain.

High (fix in the first week)

7. Configure a custom auth provider for production

Built-in Base44 auth is fine for prototyping. For production, wire up Auth0, Clerk, or Google Workspace SSO so password policy, MFA, and audit logging meet your org’s standards.

8. Add rate limiting on Base44 API endpoints

Base44 doesn’t add per-IP throttles by default. Add rate limiting on every action endpoint, especially auth, password reset, and any LLM-calling action.

9. Review generated email templates for HTML injection

Email templates that interpolate user input ({{ user.name }} directly into HTML) are vulnerable to email-rendered XSS for any client that follows links. Sanitize before interpolation.

10. Restrict who can edit the Base44 app

Audit the team list. Editors can change permissions, integrations, and code. Remove anyone who shouldn’t be there; downgrade where you can.

11. Verify webhook handlers check signatures

Stripe, Resend, GitHub all sign webhooks. Base44 actions that receive webhooks usually skip signature verification by default — fix this before payments go live.

12. Disable email enumeration in the auth flow

Confirm signup, password reset, and magic link return identical responses for “user exists” and “user does not exist.”

Medium (fix when you can)

13. Remove sample data and demo users before launch

Templates ship with demo users like admin@example.com / password. Delete them.

14. Restrict file upload sizes

Cap by file size in the field configuration. Without a cap, a single malicious upload can consume your storage quota.

15. Set up monitoring for unusual entity access patterns

Base44 logs API calls. Ship them to a tool that alerts on patterns like “single user reads 10,000 entities in 30 seconds” — that’s enumeration.

16. Document each entity’s access model

Maintain a written record of which roles can read/write each entity and why. When templates regenerate, you have something to diff against.

17. Audit installed integrations for least privilege

Each integration has scopes. Audit each — if the Stripe integration only needs to read customers, don’t give it write.

18. Set up audit logging on auth events

Ship Base44’s auth logs to a tool you can query long after default retention expires.

After every Base44 regeneration

• Diff entity permissions before/after the regeneration.
• Confirm no debug pages, admin bypasses, or seed-data routes reappeared.
• Re-test cross-user access (sign in as B, try to read A’s data).
• Audit any new integrations for hardcoded keys.
• Verify dashboards are still scoped to authenticated access.

Common attack patterns we see in Base44 apps

The “everyone can read” entity. Orders entity left at default permissions; signed-in user iterates IDs, dumps every order including credit card masks and addresses.

The hardcoded admin bypass. Template’s /dev-login page survived to production. Anyone with the URL is admin.

The public dashboard leak. Public dashboard aggregates Users entity with name and signup date; URL gets indexed; competitor scrapes the customer list.

The unsigned Stripe webhook. Action handler reads event.type === 'invoice.payment_succeeded' from body and credits the user — without verifying the Stripe signature.

Related Resources

How to Secure Base44

Step-by-step guide for hardening a Base44 app — entity permission patterns, integration security, and the auth-provider migration above in long form.

Is Base44 Safe?

In-depth analysis of Base44’s defaults — what’s locked down, what’s open, and what we find when we audit a typical app on the day it launches.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through your Base44 deployment, attempts the cross-user IDOR and unsigned-webhook attacks above, and reports what got through — with the entity or action to fix.