Your builder checks some of it. Your own checks find the common gaps, starting with database rules.
We can't tell you from here that your app is safe, and no scan can. What you can do is check the places where AI-built apps most often leave gaps: whether users can see each other's data, who can log in, and where your keys sit. Here is the order we'd check them in. Vendor pages read 23 October 2026.
Doesn't my builder keep my app safe?
Partly. Lovable, Bolt, Replit and Base44 each run a check of some kind. Lovable and Base44 also say in writing that your app's security is yours. So your builder's check is a start, and the rest is your job.
The gaps worth checking are these, in the order we'd check them. That order is ours, set by what the sources below show most.
- Other users seeing data or files. One customer opening another customer's orders, or a file link that anyone can open.
- Login. Sign-in, password reset and admin pages letting the wrong person in.
- Keys. A secret key sitting where a browser can read it.
- Payments. An app that unlocks something without checking the payment really happened.
- Bills. A key for a paid service, such as AI or email, that lets a stranger run up your costs.
Many of the loud warnings online come from people selling a scanner or a service, so we keep this page calm and specific.
What to do next: How do I check my app's security myself? gives the order. Is Lovable safe? and What do Bolt, Replit and Base44 check for you? give each builder's own checks.
How do I check my app's security myself?
Here is a short security checklist you can run yourself, in this order. It finds common problems and does not make an app safe.
Run your builder's own check first. Lovable has a Security view, with a Quick scan at publish and a Deep scan you start yourself. Bolt has Run security audit. Replit has the Security Center. Base44 has Run Security Scan. Each vendor says to run its check before you publish. The details are in Is Lovable safe? and What do Bolt, Replit and Base44 check for you?.
Run Build Check. Our free tool is at tools.onekode.co/build-check. Paste a link to your code, for example a GitHub repository such as
github.com/you/app. It takes about two minutes, it is free, and there is no sign-up. Your code is read, never run, never kept. You get a score for each of four areas (Security, Scalability, Ownership and Stability), what blocks launch, and a fix prompt for each problem. Build Check can't read Bubble apps, or FlutterFlow apps without a code export, yet. Do steps 3 and 4 and ask for a person (see When should a person look at it?).If your app uses Supabase, open the Security Advisor and read the warning titles. What is Supabase RLS? explains them.
Run two hand tests.
(a) Sign in as a second user and try to open the first user's page.
(b) In a private window, signed out, open one of your file links and try an upload.
Run it again at the right times. Before your first real user, before you take payments, and after any big change. Base44 says to run its scan after significant changes. Bolt warns that restoring an earlier version also removes its security fixes.
If you would rather have a person look, that is further down.
What is Supabase RLS, and can my users see each other's data?
Row Level Security (RLS) is a Supabase setting that decides which rows each user can read or change.
With RLS off, anyone holding your app's public key can read and write the table. With RLS on and no rules, nothing gets through. With a rule that lets everyone in, it looks on but protects nothing.
Here are the four cases side by side (Supabase's Row Level Security doc, read 23 October 2026).
| Where the table stands | What a stranger holding your public key can do |
|---|---|
| RLS off | Read and write the table. |
| RLS on, no rules | Nothing. No data comes through the API until you add rules. |
| RLS on, a rule for everyone | Everything. A rule written as "using (true)" for the public role exposes every row. It is only for data that is meant to be public. |
| RLS on, rules that match each user to their rows | Only what each rule allows. |
Views skip RLS unless set up with security_invoker = true.
The Security Advisor. In Supabase, open Studio, then Advisors, then Security Advisor. It lists warnings by title. The warnings you may see include:
- "Table publicly accessible": RLS is off on a table in the
publicschema. This is the one people search for as "RLS disabled in public". - "Security policy not enforced": a rule exists, but RLS is off.
- "No access rules defined": RLS is on, with no rules.
- "Security policy allows unrestricted access": a rule for everyone.
- "Sensitive data publicly accessible".
Supabase says some findings may be intentional, for example a table that really is public. The titles are from Supabase's Database advisors doc.
The two-account test. Sign in as a second user and try to open the first user's page, order or profile. If it opens, the rules are missing or open to everyone. Ask your builder to add the rule (What should I fix first? has a prompt). This test checks one thing only.
The turn-RLS-off trap (our label). If your builder, or an error message, points you at turning RLS off to make an error go away, don't. Fix the rule instead. "Trap" is our word; the study above found errors cleared by weakening a security control.
Files. A public storage bucket means anyone who has a file's link can open it. Uploads, deletes and moves still need rules. A private bucket goes through the same RLS rules, and files are opened by a signed-in download or a signed link. Hand test (b) is the quick way to try this.
To write rules, use Supabase's Row Level Security doc; we don't teach policy writing here. Build Check's Security score includes this check: tools.onekode.co/build-check.
A missing rule is a fix, not a rebuild (Keep, fix or rebuild your app). For how the database is set up, see How do I set up my app's database?
Can someone get in where they shouldn't?
This is the second thing to check, after data.
Sign-in, password reset, sessions and admin pages count as one check, because a gap in any of them lets the wrong person in.
Here is what each builder's scan says it looks at (their docs, read 23 October 2026):
- Bolt's audit looks at sign-in and password rules, and whether public parts of the app reveal private data.
- Lovable's Deep scan looks at access control, unauthenticated endpoints and auth.
- Base44's scan looks at user fields that control access and at backend functions that anyone can call without signing in.
One more case, and this one is our reading from Build Check's check, with no vendor doc read on it: an admin page that is decided in the browser. The page only hides the link, and anyone who types the address gets in. If your admin area works that way, ask for a person to look.
Why second: authentication failures appeared in 51.5% of the same study's 200 apps (arXiv 2606.23130, version 4). In the 437 builder posts we read, login or auth is the most named topic (99 posts; our count, 23 October 2026, and it includes login bugs that aren't security, so we say "most named", not "most common failure"). And 26 of the 34 AI-builder security jobs we found on Upwork ask for it, which is one marketplace.
Setting up login is a different job: How do I set up login and user roles?
Are my API keys out in the open?
Any key your browser can read is public, so a secret key must never be there.
Supabase has two kinds. A publishable key is "Safe to expose online", because it reaches only what your rules allow. A secret key is different: Supabase says "Never put one in a browser, a shipped application, or source control." The older names are anon for the public one and service_role for the secret one, and service_role skips RLS entirely. Source: Supabase's API keys doc.
In older Lovable apps, anything with a name starting VITE_ ends up in the browser. Lovable's FAQ says apps created before 13 May 2026 use React and Vite, and Vite's own doc says variables prefixed VITE_ are exposed in client-side code (Lovable FAQ; Vite, Env variables and modes). We make no claim here about newer Lovable apps, or about other builders. The rule that covers every builder is the general one: anything the browser can read is public.
Where secrets belong: Lovable steers keys pasted into chat into Secrets, called from server code. Replit has Tools, then Secrets, and warns that hard-coded secrets can be exposed when you share code or push to a public repository (docs read 23 October 2026).
If a key has leaked, make a new key and delete the old one. Moving it is not enough. This is Build Check's rule. And if you ever pasted a key into a public Lovable project's chat or code, replace it (our advice, after the April 2026 incident below).
One line on bills: a key for a paid service, such as AI or email, sitting in the browser lets anyone run up your bill.
Can someone fake a payment?
They shouldn't be able to. Your app should unlock something only on a message it has confirmed came from the payment company, and the browser should never set the price or the "paid" flag.
How that works is covered in Why did they pay but nothing unlocked?, in our payments guide.
Is Lovable safe?
Lovable checks some things for you, and says the rest is yours.
Here is what its own pages say (Security doc and Security page, read 23 October 2026).
A Quick scan runs each time you publish. It checks the database, including RLS, plus dependencies and connected MCP servers for endpoints that need no sign-in. A Deep scan adds a review of the code: access control, unauthenticated endpoints, injection, leaked secrets, payments, auth and exposed personal data. You start it yourself from the project's Security view ("Run deep scan"). The publish dialog runs the Quick scan, and links you to the Security view if it shows issues. It doesn't start a Deep scan. Findings are labelled Critical, Warning or Info. Auto-fix covers some database and dependency findings, not Deep scan findings.
Lovable's own limit, in our paraphrase: its tools can't promise complete security, you are responsible for your app's security requirements, and for sensitive data it recommends a professional review.
Two dated incidents, so you can tell app settings from the platform:
- CVE-2025-48757, published 30 May 2025. The record says an insufficient database RLS policy in Lovable through 15 April 2025 allowed remote reading and writing of tables in generated sites. It is tagged "disputed", because Lovable says each customer is responsible for their own app's data. It was about app settings.
- Lovable, April 2026. In a post on 22 April 2026, Lovable said that between 3 February and 20 April 2026 the chat history and source code of public projects could potentially be accessed by other Lovable users with a project link. It says private projects and Lovable Cloud were never affected. This was the platform, not app settings.
Sources: Lovable Security doc, Security at Lovable, the CVE record, Lovable's April 2026 post.
What do Bolt, Replit and Base44 check for you?
Each has a built-in check. None of them promises your app is secure.
Labels are copied from each vendor's docs; we haven't seen them in the product, so "its docs call it" applies to every row.
| Builder | The check | Where | When it runs | Plan |
|---|---|---|---|---|
| Bolt | Run security audit. It reviews code and database, fixes what it can and lists the rest under "Needs your action". It looks at whether users can see or change others' data, sign-in and password rules, price tampering, input validation and exposed keys. | Publish, then Run security audit | You run it. The doc recommends once before publishing. | Paid plans. A lighter Database security check is on every plan, in the database settings' Security tab. |
| Replit | Security Center. Dependency scans, plus Agent security scans that review your code. A lightweight build-time check for hard-coded secrets does not show in the Security pane. | Tools, then Security Center | Dependency scans run automatically. Replit runs a scan before publishing. | Dependency scans are free. Agent security scans are for paid builders. |
| Base44 | Run Security Scan. It looks at data permissions, access-control fields, exposed secrets and unauthenticated backend functions. | Dashboard, then Security, then Run Security Scan | You run it, before your first publish and after significant changes. | Every plan, including free. The code-vulnerability part is Builder plan and up. |
Restoring an earlier version in Bolt also removes its security fixes. A Replit app that is published gets its own production database, separate from the one you build in.
Base44 puts it plainly: "You are responsible for your app's security." In July 2025, Wiz Research reported that sign-up endpoints on private Base44 apps could be misused. Base44's owner, Wix, fixed it within 24 hours and reported no evidence of exploitation. That was the platform.
Cursor and Claude Code don't publish your app, so the check is one you run yourself (our reading; the FAQ has the dated facts). Cursor's pages: Agent Security, Bugbot, Security Agents. Anthropic: Automated security reviews in Claude Code.
We don't say any builder is unsafe, or safer than another. Docs: Bolt Security · Replit Security scanner · Replit Secrets · Replit, Development and production databases (vendor title) · Base44, Running a security scan · Wiz, 29 July 2025.
What should I fix first?
Fix in this order. The order is ours, set by what the sources show most.
Anything that lets other users or strangers read or change users' data: RLS off or open to everyone, open storage.
Login and admin gaps.
Secret keys in the code or the browser (a new key, and delete the old one).
Payment confirmations that aren't verified, and prices taken from the browser. Why did they pay but nothing unlocked? has that.
A paid AI or email service called from the browser.
Why this order: the study's access-control and authentication shares, the 437 builder posts we read, and the 34 AI-builder security jobs on Upwork (posted on one marketplace) all point the same way, with data first.
One fix per prompt. Tell your builder to change nothing else, then run the same hand test again. A rollback undoes code, not data or database rules, so don't count on one to undo a database change (when your AI builder keeps breaking).
Prompts you can paste:
Never paste a key, token, password or secrets file.
List every table in my database that holds user data. For each one, make sure Row Level Security is on and each signed-in user can only read and change their own rows. Do not turn Row Level Security off on any table. Change nothing else. Tell me what you changed.
Never paste a key, token, password or secrets file.
Find any secret key in my code or in anything the browser can read. Move it to server-side secrets and tell me which keys I need to replace. Do not loosen any access rule. Change nothing else.
Never paste a key, token, password or secrets file.
Check my storage buckets. Make the ones holding user files private, and add rules so each user can only open their own files. Change nothing else.
When should a person look at it?
When your app holds real people's personal or payment data and nobody has checked it, or when any of these signs show.
These signs are ours:
- It holds real personal or payment data.
- A check says "not checked", or the report says "We read your code, but we have few checks for this kind of app yet".
- A fix keeps coming back, or breaks something else.
- You can't tell whether a warning is meant to be there.
- You are about to take payments.
The moments we see are the ones founders describe: staff or customers about to log in, real customer data about to be loaded, a business customer asking security questions.
If you'd rather hire someone to finish it, Hiring someone to finish an app you started helps you choose. For the items code can't show, such as backups, your domain and email, use the Launch List.
What should I do next?
The Free Build Audit is free.
A person on our team records a walkthrough of your app and sends you a one-page note on what stays, what needs fixing and what blocks launch.
It doesn't say your app is safe, and it isn't a security audit or a certificate.
Get the Free Build AuditIf the app needs the fixes done, Finish and Launch is our service for that.
Questions.
Is Lovable safe to use?
Lovable runs a Quick scan each time you publish, and a Deep scan that you start yourself from the Security view. Its documentation says its security tools cannot promise complete security and that you are responsible for your app's security requirements. So the platform checks some things, and you still check your own app. Read 23 October 2026.
Is Base44 safe?
Base44 has a Security scan, found under Dashboard, then Security, then Run Security Scan, on every plan including free. It looks at data permissions, exposed secrets and unauthenticated backend functions, among other things. Its documentation says you are responsible for your app's security, and to run the scan before your first publish and after significant changes. Read 23 October 2026.
Is Replit safe?
Replit has a Security Center under Tools. Dependency scans run automatically and are free; Agent security scans, which review your code, are for paid builders. Your published app also gets its own production database, separate from the one you build in. A scan is a check, not a promise. Read 23 October 2026.
Is Cursor or Claude Code safe to use?
That is two questions: the tool, and the app it builds. Cursor says its agent asks for your approval before terminal commands by default, which is about your computer, not your app. Cursor's Bugbot and Claude Code's /security-review can review code for security problems, but you set them up or run them. Read 23 October 2026.
Is it safe to put my Supabase anon key in the front end?
Supabase says yes, if your Row Level Security rules are in place. Publishable keys, the newer name for the anon key, are "Safe to expose online" because they reach only what your rules allow. With RLS off, that same key can read and write the table. A secret or service_role key never goes in the browser. Read 23 October 2026.
What does "RLS disabled in public" mean in Supabase?
It is a Security Advisor warning, shown as "Table publicly accessible", for a table with Supabase RLS switched off. Supabase says such a table is readable and writable by any role with a grant on it. The fix is to turn RLS on and add policies that say who can see which rows. Read 23 October 2026.
Does my builder's security scan mean my app is secure?
No. Lovable says its security tools cannot promise complete security, and Base44 says you are responsible for your app's security. A scan finds common problems, not every one. Run it, then add a check of your own, such as Build Check and the two hand tests in this guide. Read 23 October 2026.
Do I need to check again after every change?
Check before your first real user, before you take payments, and after any big change. Base44 says to run its scan before the first publish and after significant changes. Bolt warns that restoring an earlier version also removes its security fixes. A new table or login change needs a fresh check. Read 23 October 2026.