Is Lovable Safe?
Lovable is safe to build on, and it runs its own security scan when you publish. The risk is in the app it generates: CVE-2025-48757 documented Lovable apps whose Supabase tables could be read without a login. This scanner tests your published app for that, plus exposed keys and open routes, from the outside.
Lovable wires a Supabase backend and generated CRUD into your app for you, which means the security decisions - whether Row Level Security is on, whether a route checks who is asking - get made by defaults rather than by you. This scanner takes your published URL and tests what that generated backend actually answers to an anonymous request.
What we check on a Lovable app
Supabase tables reachable without auth
Pulls the project URL and anon key out of your published bundle and tries to read common tables with it. A table that never got an RLS policy answers that request.
Read more →Keys in the published bundle
Matches your JavaScript against key patterns for 30+ providers - including a Supabase service-role key, which would defeat RLS even where you enabled it.
Read more →Routes that answer anyone
Probes common unauthenticated JSON endpoints, debug routes, and admin-looking paths to see which respond without a session.
Read more →Storage buckets and RPC functions
Checks whether Supabase Storage buckets list publicly, and which Postgres functions execute for an anonymous caller.
Session and cookie handling
Flags tokens kept in localStorage, cookies missing HttpOnly, Secure, or a strict SameSite, and auth pages that allow caching.
Read more →Browser security headers and TLS
CSP, HSTS, X-Frame-Options, Referrer-Policy, and Permissions-Policy, plus certificate expiry and HTTPS behaviour.
Read more →How the Lovable Security Scanner works
- Step 1
Paste your published Lovable URL
Whatever your app is deployed at - a lovable.app subdomain or your own domain. No Lovable login, no repository export, no Supabase credentials, and no Ubserve account.
- Step 2
We test the generated backend from outside
We fetch the page, download the JavaScript it serves, extract the Supabase project URL and anon key, and use only that public key to read common tables, list storage buckets, and call RPC functions. In parallel we probe API and debug routes, inspect cookies and client storage, and check headers, CORS, and TLS.
- Step 3
You get the report, partially unlocked
You see the issue count, a letter grade, and up to two findings in full, free. The rest - including the highest-severity findings and the copy-paste fix prompts - unlocks with a one-time report unlock or a plan.
Frequently asked questions
Is Lovable safe to use?
As a platform, yes. Lovable runs a basic security scan every time you publish, covering RLS policy linting, schema review, and a dependency audit, with a deeper scan available on demand. The gap is in the generated app itself. CVE-2025-48757 documented Lovable apps whose Supabase tables answered unauthenticated reads, because Row Level Security was missing or too permissive. Lovable is safe to build on; whether your specific app is safe depends on what it actually serves once published.
Lovable already scans my app. Why use this?
Lovable's scan reads your project from the inside: it lints your RLS policies and reviews your schema before you publish. This scan never sees your project. It takes your published URL, pulls the anon key your app ships, and tries to read your tables with it, the way a stranger would. A policy that lints clean can still answer that request if it is permissive, so the outside test catches what the inside review can miss. Run Lovable's scan before publishing and this one after.
How do I know if my Lovable app is insecure?
Ask your app the questions an anonymous visitor would. Open the published site in a private window, find the Supabase project URL and anon key in the JavaScript, and request one of your tables with that key. If rows come back without a login, the generated backend is serving your data to the public. Then check whether any route that changes data works without a session. Those two answers tell you more than reading the generated code does, because they describe what is actually deployed.
Why do AI-generated apps ship with security gaps?
Because a prompt describes features, not constraints. When you ask for a dashboard that lists orders, a code generator produces a table, a query, and a page - all of which work. Nothing in that request says the table must deny anonymous reads, that the endpoint must verify the caller owns the row, or that the key must stay server-side. The result runs correctly for the person testing it while remaining open to everyone else, and it looks finished, which is why the gap survives to launch.
How does the scanner work?
It runs the standard Ubserve public scan against your published URL. We fetch the page, download the JavaScript bundles it links to, extract the Supabase project URL and anon key, and issue read-only requests with that public key against common tables, storage buckets, and RPC functions. Alongside that we probe common API and debug paths, read cookies and client storage, and check security headers, TLS, CORS, and source-map exposure. Nothing writes to your database.
Is it free? Do I need to sign in?
The scan is free and you do not need an account to run it. You get the issue count, a letter grade, and up to two findings shown in full - location, evidence, and severity - at no cost. The rest of the report stays locked, including the highest-severity findings and the copy-paste fix prompts you can hand to your AI coding tool. Unlocking everything is a one-time payment for that report, or a plan if you want repeat scans and monitoring.
Does Ubserve see my Lovable project or source code?
No. This scan only reads what your app already serves to the public: the HTML at your URL, the JavaScript bundles that page links to, HTTP response headers, TLS certificate details, and public DNS records. We never ask for a repository, a database password, a service-role key, or an app login, and we cannot see private source code or authenticated pages. When we find a secret in your bundle, we found it because your browser downloads it too - anyone viewing your site can read the same bytes.
Will scanning break my app or fill my database with junk?
No. Every request this scan makes is a read. We select rows, list buckets, call read-shaped RPC functions, and request headers and files - we never insert, update, or delete, and we never sign up a user. Requests go out a couple at a time with pauses between them rather than in a burst, so the scan looks like ordinary traffic rather than something your host should rate-limit.
What founders say
5.0 out of 5 - Ubserve, from 3 reviews
“Helped me find a critical database issue that would've done real damage. I recommend it for every founder.”
“Caught a critical CSP issue on my frontend within minutes. Don't ship without a scan.”
“The free scan took under 60 seconds to find real issues in my project.”
Other free tools
See all tools →
DatabaseSupabase RLS Checker
Probes your Supabase tables with the anon key from your own bundle to see which ones answer without Row Level Security.
Open tool →
AI BuildersBolt.new Security Scanner
Checks a deployed Bolt.new app for env values that reached the client bundle and endpoints that trust the browser.
Open tool →Exposed API Key Scanner
Downloads your deployed JavaScript and matches it against key patterns for 30+ providers, from Stripe to OpenAI to AWS.
Open tool →Keep reading
- Lovable security checklistThe pre-launch pass for a Lovable build.
- Pre-deploy security checklist for vibe-coded appsThe last pass before you ship.
- Supabase security checklist for AI-built appsLovable's backend, secured properly.
- Broken access control in AI-built appsThe failure that generated CRUD produces most often.
- Why AI security prompts gave me false confidenceAsking the model whether it is secure is not a test.
Run the Lovable Security Scanner
Paste your URL and see what your app is handing to the public. Free, no account, no repo access.