Lovable security scanner
Lovable ships working apps fast. The parts that keep an app safe (database access rules, hidden keys, server headers) are easy to skip when the app already looks finished. This page explains what usually breaks on Lovable and lets you scan your live app right now.
Scan your Lovable app
What it means
Anyone can read this table without logging in. That can be deliberate, such as reference data or a public directory, or a missing access policy; only you can say which. xlogs read one row's column names and kept none of its values.
Why AI tools cause it
Supabase only limits who can read a table once you turn on Row Level Security (RLS) and write access rules for it. An AI tool can build a working app without doing that, and a table without RLS, or with a policy that lets everyone read, answers anonymous requests.
How xlogs checks it
xlogs finds your public Supabase URL and anon key in your app (the same ones your frontend uses), asks the database for its table list, reads one row from each listed table as an anonymous user, and flags any that return rows. Hosted Supabase refuses that list to public keys, so on a hosted project the result says the tables could not be checked. Read-only: it never writes or deletes.
What to check first on a Lovable app
Three things to check first on a Lovable app: whether the database answers anyone's read, whether a secret key sits in the code the browser downloads, and whether the site sends the standard headers browsers use to block common attacks.
None of these show up while you use the app. It loads, it works, and it looks done. The only way to know is to check the live app the way an outsider would, which is exactly what the scanner below does.
The top Lovable security issues to check
- Publicly readable Supabase database (Row Level Security off)
- An API key or service key exposed in the client bundle
- Missing security headers (CSP, HSTS, X-Frame-Options)
- Source maps that let anyone download your original code
- Private files like .env served from the live site
How to fix it
The goal: Row Level Security is enabled on every table, and each table returns rows only to the users it is meant for: a private table answers no anonymous request, and a table that is public on purpose has a read policy that says so.
- Decide whether the affected spot is meant to be readable without a login
- If it is not, enable Row Level Security (RLS) on the affected spot and add a policy so only the users allowed to see a row can read it
- If it is, keep it public on purpose, and record that decision so a review does not reopen it
- Do not switch on a restrictive policy for a table your public pages read without a replacement read policy, or those pages stop working
- Re-check that an anonymous request returns what you decided it should
In my app (the spot the scan shows): anyone can read this table; confirm that is deliberate. Please make this true: Row Level Security is enabled on every table, and each table returns rows only to the users it is meant for: a private table answers no anonymous request, and a table that is public on purpose has a read policy that says so. Steps: Decide whether the spot the scan shows is meant to be readable without a login; If it is not, enable Row Level Security (RLS) on the spot the scan shows and add a policy so only the users allowed to see a row can read it; If it is, keep it public on purpose, and record that decision so a review does not reopen it; Do not switch on a restrictive policy for a table your public pages read without a replacement read policy, or those pages stop working; Re-check that an anonymous request returns what you decided it should. Then tell me exactly what you changed, and do not print any secret values back to me or write one into a commit message, a pull request description or a log.
Then verify: After you decide and deploy, xlogs repeats the same anonymous read of each table the database lists and reports what comes back: a table you made private should no longer return rows, and one you keep public still will. If the table list is refused, it says the tables could not be checked.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
Does Lovable make my app secure by default?
No. Lovable gets the app running and its own scan reviews your access rules, but the rules and headers your deployed app actually serves are still yours to check. Those are decisions about who is allowed to read what. A new Lovable app can work perfectly and still let anyone read its tables.
How do I check if my Lovable app is safe?
Paste your live Lovable URL into the scanner above. It looks at your app the way any visitor could: it reads the JavaScript your app ships, checks your response headers, and asks your database, logged out, whether its tables return rows. You get a plain-English report and a fix.
Is the scan safe to run on my live app?
Every request is a GET or a HEAD: it never submits a form, never logs in and never tries to exploit anything, and it skips links that look like actions. Besides the pages and code a browser loads, it asks for a short published list of paths where sensitive files are often left, such as /.env.