Lovable's built-in security scan vs xlogs
Lovable now ships its own security scanning, and credit where it is due: its Quick scan reviews your database access rules every time you publish, and its Deep scan reviews all of your application code. 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
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 Lovable's scan does
Lovable's Quick scan runs a fixed set of checks every time you publish: your database access rules (tables without row-level security, rules that let everyone through, leaked-password protection turned off), known vulnerabilities in your npm dependencies, and any MCP server your app exposes without authentication. Its Deep scan adds a review of all your application code: access control, unauthenticated endpoints, injection, leaked secrets, payment and sign-in logic, and personal data in errors and logs. Findings land in the project Security view. This reflects Lovable's documentation as of 6 October 2026.
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 | Flags tables without RLS and rules that let everyone through |
| 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, 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
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.