Free scan

Lovable security checklist

Run through these five checks before you share your Lovable app. Each one is a real issue we see often, and each one is scannable right now. Start with the scan, then work any items it flags.

Scan against the whole checklist

One scan checks every item on this list against your live app.

By using xlogs, you agree to our Terms, Privacy Policy, and Disclaimer.

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.

  1. Lock down your database
    Turn on Row Level Security and add a policy for every table so anonymous requests cannot read private rows.
    critical
  2. Hide your secret keys
    Keep secret keys in server-only environment variables, never in the code the browser downloads. Rotate any that leaked.
    critical
  3. Add security headers
    Set CSP, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy so browsers can block common attacks.
    medium
  4. Stop shipping source maps
    Turn off source maps in production so your original code cannot be downloaded from the browser.
    high
  5. Keep private files private
    Make sure files like .env and the .git folder are not served from your live site.
    critical

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.

  1. Enable Row Level Security (RLS) on every table, especially the affected spot
  2. Add a policy per table so only authenticated users can read/write their own rows (keep intentionally-public tables public on purpose)
  3. Re-check that an anonymous request no longer returns private rows
Paste this to your AI coding tool (Lovable, Cursor, Claude Code):
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

What should I check before launching a Lovable app?

The five items on this page cover the issues that actually get exploited: an open database, exposed keys, missing headers, downloadable source, and public private-files. Scan first, then fix what is flagged, then re-scan to confirm.

Keep going