Lovable's built-in security scan vs xlogs
Lovable now ships its own security scanning, and credit where it is due: its Basic scan includes RLS policy linting, and its Deep scan does an agentic review of your codebase. That is more than most build tools offer. xlogs is not a replacement for it. It answers the question Lovable's scan structurally cannot.
Check your deployed Lovable app
What it means
Your database tables can be read by anyone, not just logged-in users. Someone could open your app's data — customer emails, orders, private records — without ever creating an account.
Why AI tools cause it
Supabase only protects a table once you turn on Row Level Security (RLS) and write access rules for it. AI tools frequently build a working app without doing that, so the tables are wide open by default.
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 as an anonymous user which tables it can read, and flags any that return real rows. Read-only: it never writes or deletes.
What Lovable's scan does
Lovable's Basic scan is a configuration and dependency check that includes RLS policy linting, database schema review and dependency audits. Its Deep scan adds an access control review, backend endpoint checks and code-level vulnerability detection. You run it from the project security view, the workspace security centre, or the publish dialog.
That is genuinely useful, and if you build on Lovable you should use it. It sees your code and your project, which xlogs never does.
What an outside test adds
Lovable's scan runs inside Lovable, with your project. xlogs runs from outside with no access to anything, which means it checks the thing you actually shipped rather than the project it came from. It sends an anonymous request to your database and reports what came back, reads the JavaScript your live site serves, and checks the headers your host actually returns.
That matters in the gaps: after you connect a custom domain, after you export or move hosting, when a setting is applied at the host rather than in the project, or simply as a second opinion from a tool with no stake in the platform. A policy that lints clean can still return rows, and only an outside read will tell you.
| xlogs | Lovable's built-in scan | |
|---|---|---|
| Where it runs | From outside, on your live URL | Inside Lovable, on your project |
| Access needed | None. No login | Your Lovable project |
| RLS | Sends an anonymous read and reports what came back | Lints your policies for permissive or missing rules |
| Your source code | Only if you paste a public repo URL, read-only and never executed | Yes, and Deep scan reviews it |
| Dependency audit | Pinned npm dependencies checked against the OSV advisory database on a repo scan | Yes |
| Secrets in the shipped bundle | Yes, on the live site | Code-level detection in Deep scan |
| Works after you move off Lovable | Yes, on any host | Lovable projects |
How to fix it
The goal: Row Level Security is enabled on every table, with policies so a table only returns rows to users allowed to see them; no table returns private data to an anonymous request.
- Enable Row Level Security (RLS) on every table, especially the affected spot
- Add a policy per table so only authenticated users can read/write their own rows (keep intentionally-public tables public on purpose)
- Re-check that an anonymous request no longer returns private rows
In my app (the spot the scan shows): anyone can read this database table. Please make this true: Row Level Security is enabled on every table, with policies so a table only returns rows to users allowed to see them; no table returns private data to an anonymous request. Steps: Enable Row Level Security (RLS) on every table, especially the spot the scan shows; Add a policy per table so only authenticated users can read/write their own rows (keep intentionally-public tables public on purpose); Re-check that an anonymous request no longer returns private rows. Then tell me exactly what you changed, and do not print any secret values back to me.
Then verify: After you deploy the policies, xlogs repeats the same anonymous read test and confirms the table no longer returns data without a login.
Full step-by-step fix guide, with a copy-paste block for each AI tool →
Common questions
Lovable already scans my app. Why run anything else?
Because the two look from different sides. Lovable reviews your project and your policies; xlogs tests what a stranger can reach on the deployed site. Policy linting says a rule looks right; an anonymous read says whether data actually comes back. If both are clean, that is a real result.
Does xlogs need access to my Lovable project?
No. Paste the public URL. It uses only what your app already serves to every visitor, and it needs no account on either side.