Written for founders who built with an app builder.
Ordered by what a stranger reaches first. Each links to a self-check you can do today and to what our test adds.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
The table looks protected in the dashboard, yet any visitor with the public anon key can read, insert, update and delete every row.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
A script can try thousands of passwords against your login form, hammer a form that sends emails or calls a paid API, or knock the app over, and the bill lands on you.
When a request fails, users see a spinner that never ends or an empty list, assume the app is broken or their data is gone, and nobody on your side hears about it.
Without these headers a browser will happily load the app inside someone else's page, over plain HTTP, or with injected scripts, which turns an otherwise small bug into a working attack.
In a scan of apps published on one builder's showcase, about one in ten had database endpoints readable without logging in because row rules were missing (Matt Palmer (Replit, Inc.), 2025). The check that finds it takes minutes in the dashboard: open the table list and look for tables marked unrestricted, then open the Security Advisor. The first pattern below walks through it.
A scan of 1,645 Lovable-built apps found 170 (about 10.3%) with database endpoints readable without login because Supabase row-level security policies were missing or too broad; recorded as CVE-2025-48757, CVSS 9.3.
May 2025 · Matt Palmer (Replit, Inc.) · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
Compare all packages, or run the self-check first.
In this order. No secret keys in the browser bundle. Row-level rules on every table. Permission checks on the server rather than in the browser. No admin pages reachable by URL. No secrets in the repository. Rate limits on login and reset. Errors that show a message instead of spinning forever. Security headers on the production site. The list above links each check to its self-check.
A week is comfortable: the pre-launch check takes 48 hours, and most fixes are small changes you can make in a day. If launch is tomorrow, the security sweep covers the three riskiest categories in 24 hours.
Run the self-check tool for your stack. If every critical item is a confident no, launch and keep the list for your next release. If anything is unsure, the pre-launch check settles it with a second account and a report.
Other moments: before you take payments, before an investor or security review, before a client handover, after something went wrong, you received a security email.