Lovable's docs state that the security scanners help identify common issues and that users should review RLS policies early. Defaults change with the product; every row above reflects the page on the verified date.
Lovable turns a chat prompt into a working web app with a backend it calls Cloud, built on Supabase's open-source foundation. That means most Lovable apps carry a Postgres database, Supabase Auth, edge functions for server code, and a public app URL, whether or not the builder ever mentioned those words.
Testing a Lovable app is mostly testing that stack. Which tables have row-level rules, what the browser can reach with the public key, whether permission checks run on the server, and what the published URL exposes. Lovable's own Basic scan runs before publish and its Deep scan covers more. What follows is what to check beyond them.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| Frontend | New projects use the TanStack Start template (default since May 13, 2026; June 22, 2026 for Enterprise). Older projects were built on React + Vite. | docs · verified 2026-09-21 |
| Backend / database | The built-in backend (Cloud) is enabled by default for the workspace and uses Supabase's open-source foundation; every Cloud project includes a managed Postgres database. | docs · verified 2026-09-21 |
| Auth | With a connected Supabase project, login flows use Supabase Auth; social providers must first be enabled in the Supabase dashboard. | docs · verified 2026-09-21 |
| Hosting | Apps publish to [subdomain].lovable.app by default. On Free and Pro plans anyone with the link can visit the published app; custom domains need a paid plan. | docs · verified 2026-09-21 |
| Secrets / env vars | Secrets are stored in the backend (Cloud secrets or the Supabase project's edge function secrets) and read by edge functions; the docs state they do not appear in app code or the repository. | docs · verified 2026-09-21 |
| Source access | GitHub two-way sync; repositories created by Lovable are private by default on every plan. Full codebase download is a paid-plan feature; the Free plan editor is read-only. | docs · verified 2026-09-21 |
| Database access rules | Lovable sets up RLS policies automatically when it builds features that store user data. The RLS policies view under Cloud > Database is read-only; changes go through chat. | docs · verified 2026-09-21 |
| Payments integration | Stripe secret key is stored as a backend secret STRIPE_SECRET_KEY and called from edge functions. By default the integration runs without webhooks and queries Stripe for payment status; webhooks are added on request. | docs · verified 2026-09-21 |
Documentation home: docs.lovable.dev/
42 patterns in the catalogue name Lovable; the most severe are listed here across secrets and keys, data access, login and permissions, payments, ai features. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
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.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Signed-out visitors or other customers can read rows meant for one account, while the owner sees an empty page and nobody notices.
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
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.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.
Whoever can influence the model's input can delete tables, email your whole customer list, or trigger any other action the app has wired up.
Anyone who views the page source can take the key and run up charges, send messages or pull data on your account until the key is revoked.
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
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
Moltbook, a social network for AI agents built with AI-generated code, ran a Supabase database without row-level security policies, leaving 1.5 million API tokens and 35,000 email addresses readable and writable without login.
Feb 2026 · Wiz Research · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Security scan (Basic)
Runs automatically before publishing: RLS policy linting, database schema review, and an npm dependency audit that re-runs when dependency files change.
Where it stops: Basic scan does not include access-control review, endpoint protection checks or code-level checks; those are in Deep scan, which runs on demand.
vendor docs · verified 2026-09-21
Security scan (Deep)
Adds access-control review, backend endpoint protection checks, code-level checks (exposed secrets, unsafe input handling, insecure storage settings, information leakage) and project-specific issues from security memory.
Where it stops: Does not run automatically as you work; the docs state the tools identify common issues and do not claim complete coverage.
vendor docs · verified 2026-09-21
Backend secrets
API keys are entered once, stored server-side and used only from edge functions; the value is not shown again and does not appear in code or the repo.
Where it stops: Only covers values you store as secrets; anything written into frontend code is visible to users, per the security best-practices page.
vendor docs · verified 2026-09-21
Private repositories
GitHub repositories created by Lovable start private on every plan.
Where it stops: Visibility of the published app is a separate setting; on Free and Pro anyone with the link can open the published app.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.service_role and then for sb_secret_.supabase.co, and read the apikey header under Request Headers.Lovable pre-launch checklist
42 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your app and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
An audit of a Lovable app checks four things. The Supabase tables behind it for row-level rules. The JavaScript sent to the browser for keys. Every edge function for its own permission check. The published URL for what a stranger can reach. Our security sweep does this in 24 hours; the pre-launch check adds reliability and deploy settings.
Lovable's docs describe the Basic scan as RLS linting, schema review and a dependency check before publish, and the Deep scan as adding access-control and code-level checks. The docs also say the scanners help identify common issues. A scan is a good first pass; an independent test with a second account and script-driven probing finds what the linter cannot, such as logic that is technically valid but wrong for your app.
Run the self-check for Supabase on this site first: table rules, keys in the bundle, permission checks on edge functions. If every answer is a confident no, you are in good shape; if any answer is unsure, the security sweep or pre-launch check will settle it before your first users arrive.