In July 2025 Wiz Research reported a flaw in Base44, the AI app builder owned by Wix. It was a platform-level problem, not something any individual app owner had done, and Wix fixed it fast. That makes it a useful story for a different reason: it shows where the platform's responsibility ends and where yours begins.
What Wiz found
Base44's authentication service had two undocumented endpoints, one for registration and one for verifying a one-time password (OTP, the short code sent by email to confirm a login). Both accepted an app_id value that is not a secret; it appears in the app's URL and in the path to its manifest file. With that value, anyone could create a verified account on a private Base44 app and walk in as a logged-in user.
Wiz reported the issue to Wix on 2025-07-09, the fix was verified on 2025-07-10, under 24 hours later, and public disclosure followed on 2025-07-29 (Wiz Research, 2025). Wix reported no evidence that the flaw had been abused.
What to check in your own app, on any builder: sign in as an ordinary user, open the browser's developer tools and see which requests your app makes. Then follow Authorization enforced only in the browser to test whether the server checks who you are on each of them.
Why it matters for apps that were never on Base44
The flaw was in the front door. Once inside, an attacker would have been an ordinary authenticated user. Whether that user could read other people's records, call admin functions or change a plan depended on each app's own permission rules, which the platform fix did not touch.
That is the general lesson. Login answers the question of who this person is. Authorization answers what this person is allowed to do, and it has to be answered on the server, for every request, using the identity the server itself verified. Every hosted auth provider can have an incident. When it does, an app whose own permission rules run on the server loses little. An app that relies on the login screen as its only gate loses everything behind it.
Two patterns from our catalogue describe the gap:
- Authorization enforced only in the browser: the interface hides the admin button, but the API route behind it answers anyone who knows its address.
- Tokens trusted without server verification: the server reads the user id out of a JWT (a signed token that carries who you are) without checking the signature, so an edited token is believed.
Both are checks a non-engineer can run with two test accounts and the browser's Network tab. The pattern pages walk through each step and describe the bad result.
What Base44 itself provides
Base44's documentation, as we read it on 2026-09-21, states that data permissions are set up automatically as you build. The rule types are All Users, Creator Only, Entity-User Field Comparison and User Property Check, and the AI asks approval before changing existing rules. Every app has two roles, Admin and User, and visibility can be Private, Workspace or Public. A security scan checks data permissions, exposed secrets, unauthenticated backend functions, dependencies and security headers, and the docs recommend it before first publish and after significant changes. The docs also note the limits: code vulnerability scanning needs the Builder plan or above, fixes are not applied automatically, and the platform states that you are responsible for your app's security.
Those rules are the permission layer this post is about. The check is whether each entity's rule says what you meant. A rule of All Users on an entity that holds customer records is the thing to look for, and the recommendations panel in the visual editor will often point at it.
The pattern to test with two accounts
- Create two accounts and add one record in each.
- In account A, open a record and copy its address, or copy the request from the Network tab.
- In a private window, sign in as account B and load that address, then try the edit and delete actions.
- A bad result is account A's record appearing for account B. Full steps: Record ids accepted without an ownership check.
This is the test that would have limited the damage from any front-door flaw, on Base44 or anywhere else.
Where testing comes in
Wix did its job: it fixed the platform inside a day. Your app's permission rules are still yours to check, and that is a separate job. When we test an app, we map every API route and server function the browser can reach. We call each one signed out, as a normal account and as a second account, ignoring what the screen shows. The Base44 hub lists the patterns we test for on this builder, and the security package covers the full set.
What to do this week
- Run the two-account test on your most sensitive record type: Record ids accepted without an ownership check.
- Call one hidden route directly as a normal user: Authorization enforced only in the browser.
- Take the self-check and note which auth questions you answered unsure.