Is Base44 safe? As a platform, yes: it holds SOC 2 Type II and ISO 27001, encrypts data in transit and at rest, and offers a security scan on every plan. Whether your app is safe is a separate answer. Base44’s docs make each table’s permission rules your responsibility, so prove them with two test accounts before customers arrive.
Is Base44 safe? What the platform secures, and what it leaves to you
Base44 is safe at the platform layer and unproven at the app layer. The company runs certified controls, encryption and a security scan; the permission rules on each table, the backend functions and the integrations are the owner’s to set and to test, and Base44’s certificates speak for Base44’s own controls, not for those rules.
Base44 draws the same line itself. Base44’s security overview tells owners: “You are responsible for your app’s security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish.” The trust center describes the SOC 2 Type II report as an “independent audit of the design and operating effectiveness of our security controls”, which is Base44’s control set, not the tables inside your app. This split is common to managed platforms, and it is the reason the managed-platform defaults that ship open are worth checking before launch. So the honest reply to anyone asking whether Base44 is safe and secure has two parts, one per layer.
The table below answers how secure Base44 is, one control at a time, and who has to act on each. Whether Base44 is safe to use for an app with paying customers comes down to the bottom three rows.
| Control | Who provides it | How you check it |
|---|---|---|
| Certification: SOC 2 Type II and ISO 27001 | Base44 | Request the SOC report from the trust center |
| Encryption: TLS 1.2+ in transit, AES-256 at rest | Base44 | Nothing to set; the trust center states it |
| Penetration testing of the platform by internal and third-party teams | Base44 | Nothing to set |
| Permission rules on each data table | You (Base44 sets starting rules as it builds) | The two-account test below |
| Backend functions and the API keys they use | You | Call each function as the wrong user; keep keys in the secrets vault |
| Checks on paid features | You | Call the paid action from a free account (check 7 below) |
Is Base44 legit, or a scam?
Base44 is a legitimate AI app builder, owned by Wix since its June 2025 acquisition, with a public trust center and a way to report security issues. The scam complaints on Trustpilot describe charges after cancellation and spent credits, not stolen data, and Base44’s terms say credits used on output that misses expectations are not refunded.
Base44 here is the AI app builder, not Base64, the text encoding. Wix’s acquisition announcement, dated June 18, 2025, puts the price at “initial consideration of approximately $80 million plus additional earn-out payments paid through 2029”. If the question is whether Base44 is trustworthy as a company, the evidence is public: a named owner, a trust center with a “Report a Security Issue” button, and a bug bounty program.
The Base44 complaints on its Trustpilot profile are a different kind of problem. They describe credits used up by AI mistakes, an AI that gets stuck on a fix, updates that do not reach the live site, publishing errors, charges that continued after cancellation and slow support; none of the reviews on the page describes a breach or stolen data. The money side has a mechanism. Base44 meters message credits and integration credits separately, and its terms say unused credits currently do not roll over to the next month. Section 10.4 of Base44’s terms of service adds that credits consumed when the output “does not meet your expectations or intended use” will “not be restored, re-credited, or refunded”. The per-plan arithmetic is in how Base44’s two credit meters work.
On this evidence, calling Base44 a scam is a complaint about a billing model, and a billing model you dislike does not expose anyone’s records. Whether Base44 is legit and whether it is safe for your customers need different evidence: the company’s public record settles the first, your own table rules the second.
Base44 security concerns: the 2025 vulnerability reports
Base44’s public security record holds two 2025 vulnerability reports: Imperva’s set of platform flaws, including premium features enforced only in the browser, and Wiz’s registration bypass on private apps. Wiz says the fix for its finding came within 24 hours; Imperva says the vendor moved quickly to implement fixes.
Both researchers disclosed privately before publishing, and both write-ups sit on their own company blogs.
| Report | When | What it found | Status |
|---|---|---|---|
| Imperva | Reported March 2025; published August 27, 2025 | In Imperva’s words: “an open redirect that leaked access tokens”, stored cross-site scripting (XSS), “insecure authentication design, sensitive data leakage, and client-side-only enforcement of premium features” | Partial fixes deployed in March 2025; “additional fixes and architectural changes in progress” in April 2025 |
| Wiz | Reported July 9, 2025; published July 29, 2025 | Undocumented registration and email verification endpoints through which an outsider could have created a verified account on a private app, using only its non-secret app_id | Fixed “within 24 hours”; Wiz verified the fix on July 10, 2025; Wix reported no evidence of past abuse |
The Imperva report reads best as a chain, not a list. Editing an app’s AI-generated code was a premium feature, and Imperva found it “only enforced client-side”, so the code of an app could be changed to carry arbitrary JavaScript that then ran “within the privileged context of app.base44.com”. That script could reach “authentication tokens stored in the browser local storage”, and Imperva’s own summary is that “combining the weak premium feature enforcement with this stored XSS” gave attackers “a clear path” to account takeover. A paid feature that was checked only in the rendered page could let an attacker reach far more than the feature.
Our reading of the lesson: a check that lives only in the browser is not a check. That case was Base44’s to fix, and Imperva reports it moved quickly to do so. The same shortcut inside an app built on Base44, a paid button hidden from free accounts while the function behind it never looks at the plan, is the owner’s to find, and the fix is to enforce plan limits on the backend.
Base44 security today: the trust center, the scan and the bug bounty
Base44 security today rests on four public pieces: SOC 2 Type II and ISO 27001 certification, a security scan that flags open table permissions and exposed credentials, a bug bounty that researchers join by invitation through Wix, and a trust center that lists the vendors handling app data.
Base44’s trust center is the one page to read first. It lists the two certifications, encryption “in transit with TLS 1.2+ and at rest with AES-256”, penetration testing by “internal teams and third-party firms” based on OWASP methodologies, a subprocessor directory, and the “Report a Security Issue” button for anyone who finds a flaw. The Base44 trust center also offers the SOC report on request, which is the document a customer’s security reviewer may ask about.
The scan is the part an owner runs. Base44’s security scan documentation says it checks for seven types of issues:
| What the scan checks, in Base44’s words | Plan |
|---|---|
| Data permission issues: a table “missing permission rules”, or people with “more access than they should” | All plans, including Free |
| Exposed secrets: API keys, passwords or tokens “somewhere app visitors could access them” | All plans, including Free |
| Unauthenticated backend functions: a function that “gives out data without checking who the person is first” | All plans, including Free |
| Credit protection: credit-using features such as AI, image generation or email that “can be reached directly from outside your app” | All plans, including Free |
| App dependencies: a third-party library with “a known security issue” | All plans, including Free |
| Code vulnerabilities: patterns such as “missing access checks, unsafe handling of user input” | Builder plan and above |
| Security header recommendations: X-Frame-Options and Permissions-Policy | All plans, including Free |
The scan does not change anything on its own. Base44’s words are “The scan does not apply fixes automatically”, and each finding comes with a recommended fix you apply with a click; Base44 creates a checkpoint before each fix, so a bad one can be reverted. Run it before the first publish and again after any significant change, which Base44’s FAQ spells out as adding data tables, updating permissions or connecting integrations. When the scan flags a credential, the place it belongs is covered in keeping an AI-built app’s keys safe.
The bug bounty, and how a researcher reports a flaw
Base44’s bug bounty is a program researchers ask to join: the trust center’s “Ask for an Invite” button opens an email to Wix’s bug bounty address. The trust center says the security team “reviews and validates every submission, prioritizes confirmed vulnerabilities by severity and fixes them”. In our view, that covers Base44’s platform: the trust center describes researchers who “probe our systems”. A flaw in your own table rules or functions sits outside that, and it is yours to find.
The limits Base44 documents for higher-risk apps
Base44’s security overview answers a few questions that matter once an app holds sensitive records. In its own words:
- Authentication tokens are stored in the browser’s localStorage; “HttpOnly cookie storage is not currently available.”
- “Per-app CORS configuration is not currently available”; Base44 manages CORS at the platform level.
- Content-Security-Policy and Strict-Transport-Security “are not configurable at the individual app level.”
- Each app can choose who may embed it (Anyone, Only these sites, or No one) and restrict browser features such as the camera, microphone and location; these are the X-Frame-Options and Permissions-Policy headers the scan recommends.
- “All public endpoints are rate-limited by default.”
- Permissions apply to whole tables, “not individual fields”, so a field that some users must not see needs a backend function that filters it out.
The first and third items belong together. Imperva’s 2025 chain worked because injected script could read tokens from local storage, and a content security policy is the header meant to limit which scripts a page will run. A header the app cannot set is a header the threat model has to account for; the background is in what a content security policy does.
Are Base44 apps secure? The failure classes to test for
Base44 apps are as secure as the rules their owners set. In third-party apps we audited, 7 of the 21 had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data, and 10 of the 21 trusted the client: the server accepted whatever the browser asserted.
All 21 are third-party apps from our June and July 2026 audits. They are a selected set rather than a random sample, so treat the counts as failure classes worth testing for, not as a rate for Base44 apps or for any one builder. In the same 21 apps, 9 had row-level security gaps.
On Base44, we’d expect those classes to show up in three places. A table whose Read rule lets every signed-in user see every row means users can see other customers’ data the moment a second customer signs up. A backend function that takes a record ID from the browser and never checks who is asking hands that record to anyone who changes the ID. A paid action that the screen hides from free accounts, with no plan check on the server, is open to any account that calls it directly. The general name for the first two is broken access control, and the same question asked of every builder is covered in whether vibe-coded apps are safe in general.
None of this says your app has these gaps. It says where to look, and the test further down is how to look.
How Base44 permissions and data access work
Two settings decide who reaches a record in a Base44 app: the app’s visibility, which controls who can open the app at all, and each table’s permission rules, which control what a signed-in person can do with each record.
Row Level Security rules on each Base44 table
Base44’s Row Level Security rules are set per table and per action: Create, Read, Update and Delete each take their own rules. A user who matches any one rule gets the action, and switching on All Users opens it to people who are not signed in.
Base44’s permission settings documentation names four rule types and pairs each with the data it suits:
| Rule type | Who it lets in | When it fits |
|---|---|---|
| All Users | Anyone, “even without signing in” | Public data like a product catalog or blog |
| Creator Only | Only the person who created the record | Personal data like orders, messages or form submissions; a user portal |
| Entity-User Field Comparison | A person whose account property matches a field on the record | Records assigned to people; a multi-tenant app matching the record’s company_id to the user’s |
| User Property Check | People with a set account property, such as the admin role | Role-based access, like admins only |
Three details from the same page decide how these rules behave. Each action is a separate checkbox, so a table can be locked on Read and wide open on Delete. The rules combine with OR: “If a person matches any one rule, they get access.” And enabling All Users on an action that already has narrower rules clears those rules, after a confirmation dialog.
That OR is how a multi-tenant data leak between accounts can start: a broad rule added next to a company_id comparison, or All Users left on Read from an early prototype, and one customer’s records reach another’s. Set the app’s visibility first (Private, Workspace or Public), then the table rules. Permission changes take effect immediately, and Base44 suggests testing in Preview mode by signing in as different roles. The same rule written in Postgres is explained in row level security on Supabase.
Base44 data security: who can reach the data
Base44 data security has three facts an owner should know before customer records go in. First, the trust center’s subprocessor directory names ten vendors: Mongo (data storage and hosting), SendGrid, Render, Google Cloud, OpenAI and Anthropic (both listed for “API calls to LLM”), Wix.com Ltd., Datadog, Langfuse and Logfire. The two model providers deserve a second look, because they matter whenever your app sends customer text to an AI feature.
Second, Base44 says its data tables are encrypted but “data is not end-to-end encrypted, which means Base44 admins can access your data if needed.” Third, workspaces on the Enterprise plan can opt their data out of AI model training.
Two things follow for your own app. An app that passes customer text to a model also takes on prompt injection risk. And your own privacy notice has to name the vendors your app sends data to, which is part of what your own privacy policy has to list. The DPA, GDPR, HIPAA and SOC 2 report questions are covered in Base44’s SOC 2, GDPR and HIPAA status.
How to check your own Base44 app: the two-account test
The two-account test settles what no scan can: whether one signed-in user can reach another user’s records. Create two accounts with the same role, make a private record with the first, then try to read, change and delete it with the second; every attempt must fail.
The checks below follow Base44’s documented settings and our test method; run them on an app you own, in Preview or on a copy with test data.
- 01 Run the security scan from the app's Security tab, review each finding before you apply its fix, then run it again
- 02 Open every table's permission settings and read Create, Read, Update and Delete separately, noting every All Users rule
- 03 Create account A and account B with the same role; with account A, create a private record and note its ID
- 04 As account B, try to read, change and delete account A's record through every screen and every request that takes an ID; each attempt must be refused without leaking fields
- 05 Repeat checks 3 and 4 for each role, and for a signed-out visitor
- 06 Call each backend function as the wrong user, and with a missing or wrong-type field, and confirm it refuses
- 07 Sign in with a free account and with an expired one, call each paid action directly rather than through the screen that hides it, then confirm a valid paid account still succeeds
- 08 Write down every setting you changed, with its value before and after
Keep the evidence, not just the result. For each refusal, save the request, the response code and the date; for the settings, keep the before-and-after list from check 8. That record is what a customer’s security questionnaire or an investor’s technical review may ask to see, and it is what tells you, six months later, whether a new table was added without rules.
These are the checks the Production Hardening Sprint uses as proof for three of its deliverables. For 1.4, data isolation across every table, we run read and write tests as anonymous users, different roles, and separate tenants, which is checks 3 to 5. Deliverable 2.9, managed-platform security settings, is check 8: we record the before-and-after settings for each managed service, naming each risky default and its new value. For 5.4, server-side entitlements, we attempt paid operations with free, expired, and valid paid accounts, which is check 7.
Where the sprint does this
When the Base44 app is about to hold customer records or take payments, start with a free audit: a video call where we talk over with you which of the checks above matter most for your app. Running those checks, fixing the gaps in the code and writing the results down is our Production Hardening Sprint, which runs for 10 working days . The app’s current framework and hosting setup are the starting point. The ten working days begin at the agreed kickoff, once the required repository and environment access is available, which on Base44 means the code synced to a GitHub repository you control; two-way GitHub sync requires the Builder plan or higher.
Common questions about Base44 safety
Is Base44 safe for kids?
No, not for children under 13 as builders: Base44’s terms require individual customers to be at least 13, or 16 in the European Union, or the minimum age where they live, and say the platform “is not intended for individuals under the age of thirteen (13)”. An app you build for children is a separate matter, and the duties that come with it are yours as the owner.
Does Base44 use ChatGPT?
Base44’s docs do not name ChatGPT; they list OpenAI as one of three AI service providers Base44 “may use”, alongside Anthropic and Google. OpenAI and Anthropic also appear in the trust center’s subprocessor directory, and the same page lists a training data opt-out for Enterprise workspaces.
Does Base44 own your app?
No. Section 5.3 of Base44’s terms says the customer “owns all rights, title and interest in the code and applications generated by the Platform”, subject to Base44’s ownership of its own platform and “to the extent such rights exist under applicable law”, and section 4.1 says Base44 will not claim ownership of your data unless the output contains Base44’s pre-existing intellectual property. To hold a copy of the code yourself, two-way GitHub sync is available from the Builder plan up.
What happened to Base44?
Wix bought it: Wix announced the acquisition on June 18, 2025, and the trust center today is published under Wix.com Ltd. The other 2025 news was security research. Wiz and Imperva each reported flaws in the platform privately, Base44 shipped fixes for both, and the write-ups came out afterward, in July and August 2025.
Can your Base44 app keep customer data private?
The platform protects its own systems, but who can see each table in your app is up to you, and that setting is easy to get wrong. On the audit, we look at your app with you, point out where data could leak, and tell you what to fix before customers arrive.
Book a free audit →
Free · 30 minutes · No code access needed