Lovable security checklist

Run through these five checks before you share your Lovable app. Each one is something the scan reads from outside, and each item says what the scan cannot check. 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.

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.

  1. Lock down your database
    Turn on Row Level Security and add a policy for every table so anonymous requests can read only what you mean to be public.
    medium
  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.
    medium
  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, 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.

  1. Decide whether the affected spot is meant to be readable without a login
  2. 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
  3. If it is, keep it public on purpose, and record that decision so a review does not reopen it
  4. Do not switch on a restrictive policy for a table your public pages read without a replacement read policy, or those pages stop working
  5. Re-check that an anonymous request returns what you decided it should
Paste this to your AI coding tool (Lovable, Cursor, Claude Code):
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.

Common questions

What should I check before launching a Lovable app?

The five items on this page are the exposures the scan can see from outside: an open database, exposed keys, missing headers, downloadable source, and sensitive files served publicly. Scan first, fix what is flagged, then rescan to see whether each finding is still detected.