Base44 ships with permissive security defaults: every authenticated user can read every entity record by default, JWTs are stored in localStorage where any in-page script can read them, app_id is publicly known, and the platform has no built-in WAF, rate limiting beyond coarse 429s, native audit logging, or strict CSP and HSTS headers. The 32-step hardening checklist groups into seven categories: authentication and session management (SSO domain verification, MFA enforcement for admin roles, server-side session timeout), data access and row-level security (ownership filter on every list, second-account isolation testing), secrets and credentials (API keys backend-only, webhook signature validation), headers and transport (HSTS and CSP via CDN proxy), XSS and input handling (DOMPurify on HTML fields, magic-byte file validation), billing and abuse (per-user AI generation caps, anomaly alerts), and logging and incident response (external structured logs, written incident plan, documented exit plan).
Why this matters
Base44 markets itself as a code-generation platform: the AI generates working apps in minutes, and most users treat the output as production-ready. It is not. The platform ships with security defaults tuned for prototyping, and three high-severity vulnerabilities — SSO bypass, stored XSS, JWT leakage — were publicly disclosed in 2025 by Wiz (July) and Imperva (August). Every one of those was structural, not a one-off bug. The platform's permissive trust model means you have to harden manually.
This checklist, maintained by the lead engineer at Base44Devs, is the working list we run on every Base44 audit. Thirty-two items, grouped by category, each with a concrete action. If you are not yet sure whether your Base44 app is actually secure, start there and then come back to score yourself: anything below 28 of 32 should not be live with real users.
Before item 1: run Base44's Security Scan
Run Base44's built-in Security Scan first, then work this list for what it does not cover. Security Scan is available to every Base44 builder with "no plan upgrade required" (Base44, 16 June 2026). Base44's security page says it "checks for vulnerable third-party dependencies (SCA), insecure code patterns (SAST), exposed secrets, missing login checks and weak data access rules", and a later post lists backend-function risks, RLS gaps and security headers among its checks. The scan documentation is narrower on two points: code-vulnerability scanning (SAST) needs the Builder plan or above, and the header check covers two headers, X-Frame-Options and Permissions-Policy. It also flags credit-using features that can be reached from outside your app. On Enterprise, Security Center runs the same scan across up to 20 apps at a time (Base44, 6 August 2026).
Base44 is candid about what the scan is: "Security Scan is not promising your app is secure." It returns recommendations you approve. This is how its published checks line up against the 32 items below:
| Scan's published check | Items it overlaps | What this checklist adds |
|---|---|---|
| Missing login checks (backend functions anyone can run) | 2, in part | 1, 3–6: SSO domain checks on signup, token TTL and rotation, server-side session timeout, reset-flow enumeration, admin MFA |
| Weak data access rules, RLS gaps | 7, 8 | 9–12: backend-only updates, role-field stripping, enum validation, column encryption |
| Exposed secrets | 13 | 14–18: rotation after offboarding, vaulting, webhook signatures, per-integration URLs, a secrets registry |
| Security headers (X-Frame-Options, Permissions-Policy) | 21 | 19, 20, 22, 23: HSTS, a strict CSP, Referrer-Policy, a monthly TLS scan of your custom domain |
| Vulnerable dependencies (SCA), insecure code patterns (SAST, Builder plan and up) | 24–26, in part | Sanitisation and upload rules written for your app's own fields |
| Credit protection (credit-using features reachable from outside your app) | 27, in part | A per-user daily cap on AI endpoints; 28–29: credit-burn alerts, third-party spend caps |
| None | None | 30–32: external logs, an incident plan, an exit plan |
A clean scan is a good start, not a score of 32. Items 28–32 are operational, which puts them outside everything the scan's published checks look at.
1. Authentication and session management (items 1–6)
Item 1. Enforce SSO domain verification on signup, not just login
Base44's July 2025 SSO bypass worked because undocumented registration and email-verification endpoints accepted sign-ups for a private app from anyone who supplied its app_id, with nothing checking the email against the organization's allowed domains. Confirm your signup flow rejects anyone outside @yourcompany.com. Test by attempting to register with a Gmail address against a private app. If it succeeds, your bypass is unpatched at the application layer.
Item 2. Require email verification before any data access
Base44's default flow lets unverified users read entities. Add an email_verified === true check on every backend function and entity-list call. Treat unverified accounts as logged-out. This single rule blocks the most common credential-stuffing path.
Item 3. Move tokens out of local storage where possible
Base44 stores JWTs in localStorage, which any in-page script can read, and its security overview says "HttpOnly cookie storage is not currently available." Until the platform moves to httpOnly cookies, mitigate by: (a) shortening token TTL to 15 minutes, (b) rotating on every privileged action, (c) refusing to render any user-generated HTML in your app shell. The combination does not eliminate the risk but caps the blast radius.
Item 4. Add a session-timeout enforcement on the server
Front-end session timers are advisory. Add a backend function that checks token age on every privileged request and returns 401 if the token is older than your policy. Without this, a stolen token works until the platform's default expiry, which has historically been measured in days.
Item 5. Lock the password reset flow against email enumeration
Base44's default reset endpoint returns different responses for "user exists" vs "user does not exist," which lets attackers enumerate your user base. Wrap the reset call in a backend function that always returns the same generic response and 200 status, regardless of whether the email matched.
Item 6. Enable multi-factor authentication for any account with admin entity access
Base44 supports MFA but it is opt-in. Require it for any user with role-based admin permissions. If the platform's role system is not granular enough for your model, add a role field on the user entity and gate sensitive endpoints in your backend functions.
2. Data access and row-level security (items 7–12)
Item 7. Add an ownership filter to every entity list query
Default Base44 behavior is that Entity.list() returns every record in the entity, scoped only by the entity name. Convert every list call to filter by created_by === currentUser.email (or your equivalent ownership column). The change is one line per call site but you must do it everywhere — a single missed call leaks the table.
Item 8. Audit RLS rules with a second account, not just the owner account
RLS rules pass for the user who wrote them and silently fail for users with different roles. Run every list and read query as a second account with no entitlements. Anything that returns data is a leak. Repeat this for every role you support.
Item 9. Restrict client-side Entity.update() to fields the user owns
Base44's client SDK lets the browser issue arbitrary updates. Move every update through a backend function that validates the user owns the row, and returns 403 otherwise. Do not rely on the client to send the right id — assume the client is hostile.
Item 10. Reject any client request that includes a role or permissions field
If your user entity has a role column, the client must never be able to write to it. Strip those fields server-side on every update path. This blocks privilege escalation via crafted requests.
Item 11. Validate enum and foreign-key fields server-side
The Base44 SDK validates types but not value sets. A status field meant to be pending | approved | rejected will accept god_mode if your code allows it. Add server-side enum validation in a backend function for every status-like column.
Item 12. Encrypt sensitive PII at rest using a backend-only key
Base44 encrypts app data at rest with AES-256 and in transit with TLS 1.2+ (base44.com/security), but that is the platform's encryption, not yours. Its docs say the data "is not end-to-end encrypted, which means Base44 admins can access your data if needed", and any request that passes your access rules gets every field back in the clear. For sensitive columns (SSN, date of birth, financial details), add field-level encryption with a key held only in backend function environment variables. Decrypt on read in the backend, never on the client. Field encryption does not lift Base44's terms of service, which bar protected health information and payment card data from the platform unless Base44 has expressly agreed in writing, so HIPAA and card-data workloads need that agreement or a different home.
3. Secrets, environment, and credentials (items 13–18)
Item 13. Move every API key out of frontend code
Stripe keys, Twilio tokens, OpenAI keys — none of these belong in client-side code. The Base44 frontend is JavaScript; anything in it is a public secret. Put every key into a backend function's environment variables and proxy calls through your own functions.
Item 14. Rotate all secrets after Base44 onboarded any contractor
Base44's IDE has historically had broad team-member access to environment variables. If a contractor or freelancer ever logged into your project, rotate every secret on their offboarding date. Treat the platform's role system as advisory, not enforced.
Item 15. Disable AI access to environment variables
The Base44 agent can read your environment configuration. If you never want a key visible to the agent (and therefore in the agent's training-feedback pipeline if any), use a backend function that pulls the secret from a dedicated vault (1Password Connect, Doppler, AWS Secrets Manager) at request time rather than storing it in the platform.
Item 16. Verify webhook signatures from every third party
Stripe, Twilio, and Auth0 all sign their webhooks. Validate the signature in your backend function and reject mismatches with 401. Without signature verification, anyone who knows your webhook URL can forge events.
Item 17. Use a unique webhook URL per third-party integration
A single shared webhook endpoint is harder to scope and rotate. Give each integration its own URL path so you can disable a compromised one without breaking the others.
Item 18. Document every external integration in a single secrets registry
A spreadsheet or 1Password vault that lists every key, its rotation date, who owns it, and what breaks if it leaks. Without this, you will never rotate after a contractor offboard or a vendor breach.
4. Headers, transport, and platform configuration (items 19–23)
Item 19. Set HSTS via a CDN proxy in front of Base44
Add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload via Cloudflare or Vercel rewrite. Base44 does not expose this header configuration directly. Without HSTS, downgrade attacks on public Wi-Fi are trivial.
Item 20. Add a strict Content Security Policy through the same proxy
A baseline CSP for a Base44 app: default-src 'self'; script-src 'self' 'unsafe-inline' base44.app; connect-src 'self' base44.app *.stripe.com; frame-ancestors 'none';. Tighten further once you know your asset origins. The unsafe-inline is required because Base44 emits inline scripts; pressure the platform to fix that or accept the residual XSS risk.
Item 21. Set X-Frame-Options or frame-ancestors to deny
Block clickjacking by refusing to be framed. Either header works. Without it, an attacker can iframe your app inside a malicious page and trick users into clicking through state changes.
Item 22. Disable referrer leakage via Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin prevents URL parameters from leaking to third-party domains via the Referer header. Critical if your URLs ever contain tokens or IDs.
Item 23. Run an SSL Labs scan against your custom domain monthly
Base44's TLS configuration changes without notice. A monthly Qualys SSL Labs run catches downgrades, expired chains, and weak cipher suites before users do.
5. Cross-site scripting and input handling (items 24–26)
Item 24. Sanitize every field rendered as HTML
If any entity has a description, notes, or bio field that you render as HTML rather than text, run it through DOMPurify with an allow-list before rendering. Imperva's August 2025 stored-XSS finding is the same failure at platform scale: user-controlled code rendered inside a trusted origin, where it could reach the session token in local storage.
Item 25. Refuse markdown rendering of user content unless the renderer is sandboxed
Markdown renderers vary in safety. If you render user-supplied markdown, use a renderer with built-in HTML escaping (markdown-it with html: false) or render inside a sandboxed iframe.
Item 26. Validate file uploads server-side, not just by MIME type
A user can upload a .exe file with a image/png MIME type. Re-check the file's magic bytes server-side, reject anything not on your allow-list, and store uploads in a domain-isolated bucket so a malicious file cannot run as same-origin script.
6. Billing, abuse, and rate limiting (items 27–29)
Item 27. Cap AI generation per user per day
Base44's credit pool is shared across your whole app. A single abusive user can drain it. Add a per-user daily cap on AI-triggering endpoints and return 429 above the cap. Without this, your monthly bill is one Reddit post away from doubling.
Item 28. Monitor credit burn rate and alert on anomalies
Pull credit consumption via the platform's billing API into a Plausible or Datadog dashboard. Alert if the daily rate exceeds 2x the trailing 14-day average. Anomalous burns are usually one of: regression loops, abusive users, runaway AI agent loops.
Item 29. Set a hard ceiling on third-party paid integrations
Stripe, Twilio, and SendGrid bills can run up faster than your credit balance. Configure each integration's per-day spend cap in their dashboard, not just in your application logic.
7. Logging, observability, and incident response (items 30–32)
Item 30. Ship structured logs out of Base44 to a third party
Base44's built-in logging is shallow. From every backend function, emit a structured JSON log to Logflare, Axiom, or Datadog. Include request ID, user ID, latency, error class. Without external logs, post-incident forensics is impossible.
Item 31. Maintain a written incident response plan with platform-specific steps
Document: how to revoke a compromised user, how to rotate every secret, how to disable a webhook, how to roll back a deploy, who to contact at Base44 (and the realistic response time, which has historically been days). Print it. Test it once a quarter.
Item 32. Have a documented exit plan with timeline and cost estimate
If Base44 has a multi-day outage or another disclosure forces you off the platform on short notice, you need a pre-approved migration target. We recommend Next.js + Supabase or self-hosted Postgres + a Vercel front-end. See our Base44 to Next.js + Supabase migration playbook for the canonical version.
Common mistakes teams make
Trusting the platform's defaults. The most damaging mistake. Base44's defaults are tuned for fast prototyping; they are aggressively wrong for production. Every default should be flipped or audited.
Reviewing the AI-generated code, not the data layer. Most teams audit the JavaScript the agent emits and miss that the entity layer is globally readable. Code review without an entity-permission audit is theater.
Assuming HTTPS is enough. It encrypts transit. It does not stop XSS, account takeover, broken auth, or RLS misconfiguration.
Treating compliance like a checklist. HIPAA, PCI, and SOC 2 require continuous controls, not a one-time review. If you are in a regulated industry on Base44, see our is base44 production ready decision framework before going live.
Never testing with a second account. Most data leaks are invisible to the developer because the developer is always logged in as the owner. Every list query needs a hostile-user test.
Hardening summary checklist
| # | Item | Severity if missed |
|---|---|---|
| 1 | SSO domain verification on signup | Critical |
| 2 | Email verification before data access | Critical |
| 3 | Token TTL and rotation | High |
| 4 | Server-side session timeout | High |
| 5 | Reset flow blocks enumeration | Medium |
| 6 | MFA for admin roles | High |
| 7 | Ownership filter on every list | Critical |
| 8 | RLS audit with second account | Critical |
| 9 | Backend-only updates | High |
| 10 | Strip role/permission writes | Critical |
| 11 | Server-side enum validation | Medium |
| 12 | Field-level PII encryption | Critical (regulated) |
| 13 | API keys backend-only | Critical |
| 14 | Rotate after contractor offboard | High |
| 15 | Vault external secrets | Medium |
| 16 | Webhook signature validation | Critical |
| 17 | Unique webhook URLs per integration | Medium |
| 18 | Documented secrets registry | Medium |
| 19 | HSTS via proxy | High |
| 20 | Strict CSP via proxy | High |
| 21 | X-Frame-Options / frame-ancestors | High |
| 22 | Referrer-Policy | Medium |
| 23 | Monthly SSL Labs scan | Medium |
| 24 | DOMPurify on HTML fields | Critical |
| 25 | Sandboxed markdown rendering | High |
| 26 | Magic-byte file validation | High |
| 27 | Per-user AI generation cap | High |
| 28 | Credit-burn anomaly alerts | High |
| 29 | Third-party spend caps | Medium |
| 30 | External structured logs | High |
| 31 | Written incident response plan | High |
| 32 | Documented exit plan | Medium |
Want us to audit your Base44 app for security?
Our $497 production audit walks every one of these 32 items against your live app, runs second-account tests, and delivers a prioritized fix list with severity scores. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. Order an audit or book a free 15-minute call.
Related reading
- Base44 Production Readiness Guide — the broader launch readiness picture, of which security is one pillar.
- OWASP Top 10 in Base44 — a per-OWASP-category walkthrough of how each risk manifests on the platform.
- Base44 Authentication Patterns — concrete patterns for login, MFA, session handling, and SSO that compose with this checklist.