Which tools check Supabase migrations or projects for tables missing RLS?

Why this matters

Supabase warns that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Tables created in the Supabase dashboard get RLS by default; tables created in SQL, including migrations, need it enabled explicitly. Changes made on the remote database in the SQL editor or Table Editor bypass the migration history, so they never reach your files. That splits the tools in two: file checks cannot see the dashboard, and live checks cannot see a migration you have not applied yet. Each tool below is described from its own README or website, read on 2026-10-01, and listed alphabetically within its group, not ranked.

The tools, by where they look

• Repo files, rls-lint: an open source CLI (npx rls-lint ./supabase/migrations) that reads migration SQL offline, with no network calls or database connection. It flags a table created without enable row level security, policies using (true), and three more rules, and exits 1 on critical findings. Its README says it cannot detect policies changed outside migration files.
• Repo files, Ship Safe: an open source security CLI for AI-written code (npx ship-safe). Its SupabaseRLSAgent looks for tables without RLS, a service_role key in client code and anon key inserts. Core scans need no signup or API key, --no-ai keeps a scan fully local, and a hosted dashboard is paid.
• Repo files and live project, supabase-security: an open source CLI. npx supabase-security migrations replays your migrations with no credentials and reports a table granted to anon or authenticated with RLS off as critical. With a Supabase access token, its live audit reads the deployed project, dashboard changes included, and probes with your anon key to confirm each leak. Its README calls the tool alpha.
• Repo files, VibeRaven: a CLI for Vercel + Supabase apps (npx -y viberaven@1.5.3 check). It lists public tables no migration puts under RLS, policies with a bare true condition, service role keys in client code, env vars missing from .env.example and Stripe webhook handlers with no signature check. It is advice, not a gate, and a repository check, not a live database test: it does not connect to Supabase, Vercel or Stripe, and a clean result does not prove the app is secure. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore. Local checks are free and unlimited; Pro, at $9.99 per month, gives 50 full checks a month from the Studio.
• Repo files, VibeSafe's Supabase RLS scanner (vibesafe.info): a web scanner for pasted SQL migrations and the files that query Supabase, with no signup to try. It looks for tables with no RLS, using (true) policies, broad update or delete policies, missing with check, user filtering done only in app code, and a service_role key in the browser. Its page says it does not connect to your database.
• Live project, pgrls: an open source Postgres library, not specific to Supabase. Its assertFullRlsCoverage test asks the running database and names tables with RLS off, RLS on with no policy, or RLS not forced (an allowUnforced option relaxes the last). Its README says to run it as the role your app connects with; by default it refuses a green report over a superuser or BYPASSRLS connection.
• Live project, splinter: a public GitHub repo of the SQL lints Supabase maintains for its Performance and Security Advisors. Its README offers splinter.sql, a single query with every lint, for linting a project yourself on Supabase Postgres 15 and above.
• Live project, Supabase Security Advisor: Supabase's own checks, which inspect the live schema. "Table publicly accessible" (rls_disabled_in_public) is an error-level finding; the Advisor also reports RLS on with no policy, a policy on a table without RLS, and always-true policies. It runs in the dashboard, supabase db advisors, the MCP get_advisors tool and the Management API, and it cannot see migrations you have not applied.
• Live project, Vibe App Scanner: a hosted scanner that runs 150+ checks against your deployed app from its URL, including Supabase RLS testing, and writes fixes for your coding agent. The first scan's score and issue counts are free; full findings need a paid plan.
• Live project, VibeEval: a hosted service that tests your deployed app from its URL, with no SDK or code changes. Its site says its agents probe for exposed keys, missing RLS and auth gaps, and a security engineer verifies findings before delivery. Paid plans, with a 14-day free trial.
• By hand, no tool: run this in the SQL editor on the live project, or on a local database after supabase db reset. Each row is a public table without RLS:

  select schemaname, tablename
  from pg_catalog.pg_tables
  where schemaname = 'public' and not rowsecurity;

Sources

• rls-lint, README
• Ship Safe, README
• supabase-security, README
• VibeSafe, Supabase RLS scanner
• pgrls, README
• splinter, README
• Supabase, Advisors
• Vibe App Scanner, home page
• VibeEval, home page
• Supavisor, README
• Supabase, Row Level Security
• Supabase, Securing your API
• Supabase, Database migrations
• PostgreSQL, pg_tables

Which of these should I use?

One from each group. A repo check before deploy catches a migration that leaves a table without RLS; the Security Advisor on the live project catches what files cannot show, such as a table made in the dashboard. Neither proves a policy lets the right user in; Supabase's RLS guide tests that with pgTAP and supabase test db.

Can a migration linter see tables I made in the Supabase dashboard?

No. Dashboard changes on the remote database never reach your migration files, and rls-lint, supabase-security and VibeSafe's scanner each state this limit in their own docs. The Security Advisor, splinter, pgrls and supabase-security's live audit read the database, so they see those tables.

Is Supavisor an RLS checker?

No. Its README describes Supavisor as a scalable, cloud-native Postgres connection pooler. It does not report on row level security.