Check the Lovable app you published and the GitHub repo it syncs to. Find Supabase tables without RLS, secret keys in client code, missing headers and public source maps, with a fix prompt you can paste straight into Lovable.
Free scan, no card. Free account to see the full report. One fix included.
By severity
Lovable apps share a recognizable stack: a React front end talking directly to Supabase. That makes the failure modes predictable. Each issue below is tagged with how it gets caught.
The browser key is public. The boundary is the policy.
Browser · React bundle
Supabase Data API
Owner-only RLS
No RLS
using (true)
Edge function
Lovable ↔ GitHub sync
Repo scan reads migrations for visible RLS signals. It does not prove the deployed policies.
A React browser bundle includes a publishable key. Requests reach the Supabase Data API, where grants and RLS policies control table access. With SELECT granted, disabled RLS or an unconditional true policy can expose rows. Server functions must verify caller identity independently of a body user ID.
These are the gaps that expose user data.
If a table in the public schema is granted to the anon or authenticated role and RLS is off, anyone with the publishable key (it ships in every Lovable bundle) can read and write it through the Data API. Supabase stopped granting new tables to these roles automatically on October 30, 2026, but older tables keep their grants, and a migration that adds a grant without enabling RLS reopens the gap.
The secret key (sb_secret_…) and the legacy service-role key bypass every RLS policy. If either lands in a VITE_ variable, a hardcoded string or a committed .env file, your whole database is public.
Exploitable once someone signs up or reads your JavaScript.
A function that takes a user ID or role from the request body, or runs a service-role query without checking the signed-in user, lets one account act as another.
RLS is on, but a policy like using (true), or one that checks login without checking ownership, still lets any user read or edit other users' rows.
A strict Content-Security-Policy makes it harder to inject a script, which matters because a session kept in browser storage is readable by any script on the page. HSTS stops HTTPS downgrades, and frame protection stops clickjacking.
Give attackers a map or a foothold.
Production .map files rebuild your original source, including Supabase table names, internal routes and admin logic.
Session-like cookies without Secure, HttpOnly or SameSite are easier to steal or replay.
Uploads such as invoices, avatars or documents in a public bucket, or a bucket without per-user policies, are downloadable by URL.
Workflows with write-all permissions, unpinned actions, or no rule keeping .env files out of the synced repository.
Manual tests are things no outside scanner can prove, such as whether a policy blocks a second user. We list them because a clean scan is not the same as a safe app. The Supabase security checklist walks through each test.
How it works
Paste your lovable.app or custom domain above. The free website scan checks TLS, security headers, cookies, more than 40 sensitive paths and public source maps. Lovable apps render in the browser, so the crawler usually sees only the pages linked in the first HTML response, often just the home page.
Connect GitHub in Lovable, then scan that repository. Public repos scan without an account; private repos connect through a read-only GitHub App on Starter or Pro. This is where RLS gaps and leaked keys show up.
Every repo finding comes with a fix prompt you can paste into the Lovable chat, so the fix is made in the same project and syncs back to GitHub. On the free website scan, your one free fix includes a prompt; paid plans add one for every website finding.
Run the website scan again after publishing. Resolved findings disappear, and the comparison shows what is new or still open. A free account gets one rescan of the same site within 7 days; after that, rescans use plan credits.
Second opinion
On paid plans, the AI logic review reads server routes and edge functions in the repository and flags code that changes data without checking who is signed in, with the exact file and line.
Lovable security FAQ
The Lovable platform can be used to build secure apps, but security of the app you generate is your responsibility. Most incidents in Lovable apps come from the generated Supabase setup: tables without Row Level Security, policies that are too broad, privileged keys reachable from the browser, and server functions that trust user input. Check those before you put real user data in the app.
Yes, and you should use it. Lovable's Quick scan checks database access rules, npm dependencies and MCP servers every time you publish, and flags tables without per-record access control. The Deep scan adds a code review and runs when you start it, from the Security view, the publish dialog or chat. ScanMySaaS is an independent second check with a different view: it scans the deployed app from the outside, the way a visitor or attacker sees it, including headers, cookies, TLS and exposed files that live on hosting rather than in code. It also reads the synced GitHub repository, so changes made outside Lovable in Cursor or Claude Code are covered, and gives you a report you can rescan and share.
With Lovable's built-in backend, open More, then Database, and review the policies on each table (Manage, then Policies). If you connected your own Supabase project, check the same tables in the Supabase dashboard. In code, every create table in drizzle/migrations (newer Lovable projects) or supabase/migrations (older ones) should have a matching enable row level security statement. For projects that use Supabase, the ScanMySaaS repo scan flags tables created in SQL migrations without one. Then test with two accounts: user A must not be able to read or change user B's rows.
No. The publishable key (sb_publishable_…, which replaces the legacy anon key) is designed to be public and will always be visible in a Lovable app's JavaScript. It is only safe when every exposed table has RLS with correct policies. The secret key (sb_secret_…, which replaces the legacy service_role key) is different: it bypasses RLS and must never appear in client code or the repository. Supabase is deprecating the legacy anon and service_role keys by the end of 2026, so this is a good moment to rotate to the new keys.
Yes, on Starter or Pro. Sign in, install the ScanMySaaS GitHub App on the repository Lovable created, and pick it from the list. The app only requests read access to contents and metadata. The scan runs in the background, so you can leave the page and come back to the report.
The first website scan and public repository scans are free, with no credit card. Private repositories and the AI logic review, which reads server routes and edge functions for missing authorization, are included in the paid plans.
Start with the live URL. Free scan, no card. A free account opens the full report; one fix is included.
Free scan, no card. Free account to see the full report. One fix included.