1.A scan from inside and a check from outside
A scan from the inside reads your app the way its builder sees it: the code, the settings and the database rules. The most important database rules are row-level security (RLS): rules that decide who may read or change each row of a table.
A check from the outside uses the live app the way people do: first as a stranger with no account, then as normal users who sign up. It cannot see your server code or your database rules. It sees what the app actually does when someone sends it a request.
The builders draw the same line. Lovable’s docs say its built-in scans do static analysis: they read your code and settings and flag patterns that look risky. A penetration test (pentest: a test that tries to break into the running app on purpose) does dynamic analysis: it uses the running app and tries to exploit it the way an attacker would (Lovable: Security overview). Replit’s Level 3 scan runs a source-code review and a black-box test (a test from outside, without the source code) side by side, and says that one does not replace the other (Replit: Black-box pen tests).
2.What each builder’s own scan checks
This is what each builder’s official docs said on 1 November 2026. Plans and features change often, so check the linked page before you rely on it.
| Builder | When it runs | What it checks |
|---|---|---|
| Lovable | Quick scan: automatically each time you open the publish dialog, and when you start it. Deep scan: when you start it, for example from the Security view before you publish. | Quick scan: database access rules (such as tables without RLS, or rules that let everyone through), leaked-password protection, known flaws in npm packages, and MCP servers open without sign-in. Deep scan: all your app code, in seven areas, including access to other users’ data, endpoints anyone can call, leaked secrets and paid features a customer can reach without paying. Both are free to run. |
| Replit | A scan before every publish, a light check of the files Agent changes while you build, and package checks when new known flaws appear. Level 1, 2 and 3 scans when you start them in Security Center. | Before publish: a setting can block publishing on critical findings. Level 1 (free): known flaws in your packages. Level 2 (paid plans): an Agent review of your source code. Level 3 (more plan and project-access requirements): adds a black-box test of your running Preview from outside, as an anonymous visitor and, for apps that use Clerk sign-in, as a test user. Levels 2 and 3 are billed as Agent usage. |
| Bolt | Audit: when you click Run security audit in the Publish menu. Bolt recommends at least one check before you publish. Database check: on the Security tab of your database settings. | Project security audit (paid plans, no tokens used): your code and database. Who can see and change data, what the app shows to anyone, sign-in, misuse such as changing a price, input from visitors, and keys in the code or sent to the browser. Database security check (all plans): the same database checks as Supabase’s Security Advisor. |
| Base44 | When you click Run Security Scan under Dashboard → Security. The publish panel shows the scan status and warns you, but does not stop you from publishing. | Data permissions, profile fields users can change to gain access, private fields such as email or phone in tables everyone can read, exposed secrets, backend functions a stranger can call, features that spend your credits and can be reached from outside, flaws in packages, and two browser protections. The scan is on all plans; its code analysis needs the Builder plan or above. |
These scans are worth running. They know your app from the inside, and each one can hand its findings to the builder’s AI to fix. The builders state their limits too: Lovable says its scans do not replace a thorough security review, and Replit says a passing publish check does not mean your code has no flaws (Replit: Security scan levels).
3.Why a check from outside helps too
An inside scan judges your code and your rules. A check from outside adds three things.
- Proof, not a pattern. An inside scan flags code or rules that look risky. An outside check sends real requests to the live app and reports what came back.
- The version that is live. A scan in the editor checks your project. An outside check sees the app your customers use, at its real address, with its real data.
- What a rule really lets out. A rule can be open on purpose, and Bolt’s database check flags an open rule even when public access is what you want (Bolt: Database security settings). An outside check shows what that rule gives a stranger, so you can decide whether it is right.
Some builders also offer a view from outside. Replit’s Level 3 adds a black-box test of the running Preview. Lovable offers an optional AI pentest through a connected partner, billed by that partner, and an optional Trust center that publishes security facts Lovable observes on your live app, such as HTTPS and browser protections (Lovable: Trust center).
4.An example: an outside check on a Lovable app
Tidybook is a booking app we built with Lovable and left with common mistakes on purpose, to test checks. On 1 November 2026, LidTight checked the live app from outside, first as a stranger and then as two new test users. It found two critical problems, and two protections held:
- Anyone could read the reviews table. With no sign-in, the check counted 12 rows, with real values in the first_name, email and phone columns. It counted the rows without downloading them, read a few values only to confirm they were real, and kept none.
- An order could be marked as paid without payment. Test user A changed its own booking from “unpaid” to “paid” with one request. No payment was made. The browser decided that a payment happened.
- Two things held. User B could not see user A’s booking, and the server blocked a normal user from changing another user’s data.
We did not run Lovable’s own scan on Tidybook, so this page makes no claim about what it would or would not find. Lovable’s Quick scan reviews database access rules, and its Deep scan looks for paid features a customer can reach without paying (Lovable: Security overview). Those are the same kinds of risk, seen from the inside.
Each problem has its own guide with the fix: What can a stranger see in your app? and Can users get your paid features for free?
5.What to do before you launch
- Run the fullest scan your plan allows on the current version: Lovable’s Deep scan, the highest level in Replit’s Security Center, Bolt’s Run security audit (paid plans) or its database check, or Base44’s Run Security Scan.
- Read each finding before you apply its fix. Base44’s docs warn that a permissions fix can break a page that signed-out visitors use, and Bolt lets you go back to an earlier version if a fix changes too much (Bolt: Check your project’s security).
- If your builder can block publishing on critical findings, turn that setting on. Lovable and Replit both have it.
- If your app uses your own Supabase project, also open the Security Advisor in Supabase Studio. It runs fixed checks for problems such as tables without RLS (Supabase: Advisors). See also My Supabase public key is visible.
- Test the live app from outside as a stranger. Find out which tables, files and keys anyone can reach: see What can a stranger see in your app?
- Test it as two normal users. Sign up two accounts and check that one cannot see or change the other’s data, and that neither can get paid features without paying: see Can one customer see another customer’s data?
- Run both checks again after big changes, such as new tables, new permissions, payments or a new integration. Base44’s docs give similar advice for its scan.
6.What LidTight’s check sees, and what it cannot
LidTight is a check from outside. The free check reads only what any visitor’s browser can see, takes seconds and needs no sign-up. The deep checks, also free, sign up two test users and test what a normal user can read and change. They are meant only for your own app. They change only our own test data. To run them, tick the box under the app link; the results show on the page.
LidTight cannot read your server code, your database rules or your project in the builder, and a clean result does not prove that an app is safe. The deep checks need a Supabase database. For Base44 apps and apps with other databases, it checks only what a stranger can read today (Base44 app security). So use it next to your builder’s scan, not instead of it. The full list of steps is in Before you go live: a security checklist.