critical severity

Anyone can read this database table

This is the most common serious issue in AI-built apps. It happens when a database table has no access rules, so an anonymous request can read it. Here is what it means in plain terms, why it happens, how to check your own app, and the exact fix.

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.

Check your own app for this

Read-only. Paste your live app URL to see if this issue is present, then get the fix.

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.

Common questions

How serious is a publicly readable database?

A publicly readable database is critical. Anyone who finds your app's public key (which ships in the browser) can read the affected tables directly, including private data like emails and orders. It requires no hacking, just a normal request to your database.

Which tools cause this most often?

Any tool that wires up Supabase without prompting you to set Row Level Security: Lovable, Bolt, v0, Base44, and hand-built apps included. The tool is not at fault; the policies just have to be turned on, and that step is easy to skip.