Base44 is a different problem from Cursor or Claude Code, and the difference is the whole article. With an agent that writes code, you can go and read the code. With Base44 the backend, the database and the login system are the platform’s, not yours — so there is no file to open, no diff to review, and no repository to search. Your app’s security is almost entirely a set of choices in panels, and a panel you never opened does not look any different from one you opened and got right. Base44 is the far end of vibe coding: no code at all. Where each kind of tool fails explains why that changes what you check.
It is worth being clear about what is genuinely handled for you, because it is a lot: the platform holds SOC 2 Type II and ISO 27001 certifications, encrypts data in transit and at rest, and gives you a login system with email verification and optional two-factor that you did not have to build. That is real, and it is better than most hand-rolled equivalents. It also creates the specific trap below — when the foundation is audited and certified, it is easy to assume the whole building is.
1. Open the permissions panel on every entity
This is the one. Each entity in your app has its own access rules, and the failure that recurs is not a wrong setting — it is an untouched one. The app gets built, it works, it ships, and nobody ever opens that panel, because nothing in the process of building a working app requires you to.
Go through them one at a time and ask a question per entity: who should be able to read this, and who should be able to write it? An entity holding orders, messages, uploads, profiles or anything a user typed should almost never be readable by everyone. Do not check the ones you think are sensitive — check all of them, because the one that leaks is the one you did not think of as sensitive.
Pay particular attention to the difference between read by anyone signed in and read by the person it belongs to. Those two sound similar and are not: the first means any customer of yours can read every other customer’s records, which is the most common serious data exposure in apps of this kind.
2. Check each endpoint’s “who can call this”
Alongside entity permissions, the functions your app exposes each decide who is allowed to invoke them. The risky ones are the verbs rather than the nouns: anything that deletes, anything that sends email, anything that charges, anything that promotes a user, anything that exports.
An endpoint that reads slightly too much is a leak. An endpoint that writes and is callable by anyone is somebody quietly changing your data — and unlike a leak, you may never find out it happened.
3. Test it as a second user, not as yourself
Every check above is a setting, and settings can be read wrongly. The only reliable test is behavioural, and it is the same one that works on every platform in this series.
Sign up twice, with two email addresses, in two browsers. Create a record in account A. Now, as account B, try to reach it — through the app where possible, and by changing the id in the address where not. If B can see or change A’s record, you have found it, and you have found it before a customer did.
Do the same as a signed-out visitor. Open the app in a private window and see what loads before any login.
4. Run the built-in scan, then read what it does not cover
Base44 includes a security scan that looks for vulnerable dependencies, insecure patterns, exposed secrets, missing login checks and weak data-access rules. Run it — it is free and it is right there.
Then hold its result in proportion. A scan of this kind answers “is anything recognisably wrong”. It does not answer “is this app’s access model right for what this app does”, because that depends on intent it cannot see: whether a therapist should be able to read another therapist’s notes is a question about your product, not about your configuration. A clean scan is a good sign and not a clearance.
5. Secrets belong in the secrets manager, not in the conversation
If you have connected anything external — a payment provider, an email sender, a third-party API — you had to supply a key. Keys pasted into a chat or typed into a field meant for something else tend to persist somewhere you did not intend.
Use the platform’s secrets management for every one of them, and check the ones already in place. If you are unsure whether a key was ever handled loosely, rotate it: it costs ten minutes and removes the question permanently.
6. The things a platform cannot decide for you
Two more, brief, and both are about your obligations rather than your settings. If you collect anything personal from people in the UK or EU, you need a privacy policy that says what you collect and why, a route for someone to ask for their data to be deleted, and an answer about who else you send it to — the platform’s own compliance does not transfer to your app’s use of it. We have a longer piece on that.
And if your app calls a model, there is a spend ceiling question: is there an upper bound on what one user, or one loop, can cost you in a day? That failure is a bill rather than a breach, and it arrives just as fast. How one missing limit becomes a four-figure bill covers the shape of it.
The short version
Base44 removes the category of bug where you wrote the authentication badly, and replaces it with the category where you never opened the panel that configures it. That is a real trade and mostly a favourable one — the settings are at least all in one place and none of them require you to understand a framework. But they do require you to go and look, and a working app will never prompt you to.
Written September 2026. Base44’s screens move; the questions above are about your app’s access model, which is yours regardless of where the toggle lives this month.
Questions people ask
Is my Base44 app secure?
The platform is the secure part - Base44 holds SOC 2 Type II and ISO 27001 certifications and encrypts data in transit and at rest. What ships open is your configuration of it, and because the backend and database belong to the platform, there is no code to read that would tell you. Your app's security is almost entirely a set of choices in panels.
Where do Base44 apps usually go wrong?
The permissions panel on each entity. The recurring failure is not a wrong setting but an untouched one: the app gets built, it works, it ships, and nobody opens that panel, because nothing in the process of building a working app requires it. Go through every entity, not just the ones you think of as sensitive.
What is the difference between 'anyone signed in' and 'only the owner'?
It is the difference between a working app and a data breach. 'Readable by anyone signed in' means every customer of yours can read every other customer's records. Those two settings sound similar and are the most common serious data exposure in apps of this kind.
Is the built-in Base44 security scan enough?
Run it - it is free and it is right there. Then hold the result in proportion. A scan of that kind answers whether anything is recognisably wrong. It cannot answer whether your app's access model is right for what your app does, because that depends on intent it cannot see. A clean scan is a good sign, not a clearance.
The same question, other tools
Each of these is a different problem rather than the same article renamed — what goes wrong depends on whether the tool wrote code you can read, or configured a platform you cannot.