Base44's AI sets each entity's data permissions as it builds and can make them broader than the data needs, 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, or per-app CSP and HSTS settings. The 32-step hardening checklist groups into seven categories: authentication and session management (SSO domain verification, MFA for admin roles, server-side session timeout), data access and row-level security (access rules checked on every entity, 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 AI sets data permissions as it builds, and they are only as tight as its reading of your prompts. 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. Base44 flags risky settings, but its security scan warns rather than blocks a publish, so hardening is on you.
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 own email/password sign-up already does this: its SDK docs say "Registration requires email verification before login." Keep that intact if you add custom auth flows, and in backend functions that touch sensitive data, check the user's is_verified field and 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's documented two-factor authentication covers Base44 accounts, the people who build and manage your app: each can turn it on (SMS, an authenticator app, or both), and on an Enterprise plan (Business or Enterprise) workspace owners can require it for every member. The docs describe no MFA for your app's own users, so for admins of the live app, sign them in through an identity provider that enforces MFA (app SSO, on plans that include it) or add a second factor yourself and check it in your backend functions before admin actions. 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. Check the access rules on every entity
Base44's AI sets each entity's rules as it builds, for example Creator Only, which limits a person to the records they created, and a rule can be broader than the data needs. A table with no rules at all is open: Base44's CLI reference warns: "If no RLS is defined, all records are accessible to all users." Open every table's Permissions page in the dashboard and confirm that Create, Read, Update and Delete each match who should reach the data: Creator Only or an Entity-User Field Comparison for personal and tenant data, a User Property Check for admin-only tables, and All Users only for genuinely public data, because All Users means anyone, even without signing in. A filter in a list call is not a control: it only narrows what your page asks for, and anyone can call the SDK without it. One table left open leaks the whole table.
Item 8. Audit RLS rules with a second account, not just the owner account
A rule that looks right from the owner account can be wrong for every other role, and a denied read returns an empty list rather than an error, so mistakes stay quiet. Run every list and read query as a second account with no entitlements, or use Test Permissions in preview on each table's Permissions page, which opens your app as the person you pick (changes made while testing are saved to that person's data, so use sample accounts). Anything that returns data it should not 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 any update the entity's Update rule allows, so a broad rule means 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. Base44 has this one built in: under Browser Security in your app's settings, set iFrame embedding to No websites (or only the sites you choose); the security scan flags it when it is missing.
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 Logs page records each app's runtime and setup events, from logins and entity changes to function calls and schema changes, and filters them by user or by errors. Its docs give no retention period and describe no alerting, and function logs "are kept for a limited time." From every backend function, emit a structured JSON log to Logflare, Axiom, or Datadog. Include request ID, user ID, latency, error class. Without your own copy, post-incident forensics depends on whatever Base44 still holds.
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 (a support ticket; its docs say response times vary with ticket volume and urgency, and priority support comes with the Business and Enterprise plans). 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 rules the AI generated. The most damaging mistake. Base44's AI sets permissions and settings to get the app working, and nothing stops you publishing them unchecked. Every rule and setting should be audited.
Reviewing the AI-generated code, not the data layer. Most teams audit the JavaScript the agent emits and never open the entity Permissions pages, where one rule left on All Users exposes a whole table. 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 | Access rules checked on every entity | 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.