Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Run a read-only query against your Supabase database to spot three conditions worth reviewing: tables in public without row-level security (RLS), RLS-enabled tables with no policies, and policies whose catalog expression is literally true. These are triage flags, not proof that your app is exposed; the query does not change database objects or data.
Run the read-only Supabase security check
In the Supabase SQL Editor, run this query using a database role that can read the relevant PostgreSQL catalogs. It lists ordinary and partitioned tables in the public schema, reports whether RLS is enabled, counts policies and literal always-true policy expressions, and summarizes policy names, commands, and roles.
select
n.nspname as schema_name,
c.relname as table_name,
c.relrowsecurity as rls_enabled,
coalesce(p.policy_count, 0) as policy_count,
coalesce(p.always_true_policy_count, 0) as always_true_policy_count,
p.policy_summary
from pg_class as c
join pg_namespace as n
on n.oid = c.relnamespace
left join lateral (
select
count(*) as policy_count,
count(*) filter (
where trim(coalesce(pol.polqual::text, '')) = 'true'
or trim(coalesce(pol.polwithcheck::text, '')) = 'true'
) as always_true_policy_count,
string_agg(
format('%I (%s; roles: %s)', pol.polname, pol.polcmd,
array_to_string(pol.polroles::regrole[], ', ')),
'; ' order by pol.polname
) as policy_summary
from pg_policy as pol
where pol.polrelid = c.oid
) as p on true
where n.nspname = 'public'
and c.relkind in ('r', 'p')
order by c.relname;The query only reads PostgreSQL catalog metadata. It does not alter tables, grants, policies, or application data. For diagnostic routines, Supabase’s [MCP documentation] describes running queries with read_only=true as a read-only Postgres user and recommends scoping access to the project.
Interpret the three flags
RLS is disabled
If rls_enabled is false, review the table’s exposure and grants promptly. A table in an API-exposed schema without RLS can be read or written by roles that already have the necessary grants; the flag alone does not show whether a client can reach it. Supabase explains the interaction between grants and RLS in its Row Level Security documentation.
#1 Best Overall
RLS is enabled but there are no policies
rls_enabled = true with policy_count = 0 merits checking against the intended behavior. It can indicate a configuration mistake, but RLS with no matching policy can also deliberately deny access. Do not treat this result alone as evidence that data is exposed.
A policy expression is literally true
A nonzero always_true_policy_count identifies policies where the catalog renders either the USING condition or the WITH CHECK condition exactly as true. Such a policy can permit all rows for the roles and operations it covers. Inspect each entry in policy_summary: the policy name, command, and role scope matter, as does whether unrestricted access is intentional. Supabase’s Advisors documentation lists always-true RLS conditions as a permissive-policy warning, while noting that findings may be intentional.
Know what the query does not establish
- It checks only
public. Supabase’s Data API can expose other schemas. Check the configured exposed schemas and adapt then.nspname = 'public'filter to review each relevant schema too. - The always-true detector is deliberately narrow. It catches catalog expressions rendered exactly as
true; a zero count does not establish that policies are restrictive. More complex expressions can still be permissive. Catalog rendering can also depend on PostgreSQL version and behavior, so verify the result against your project’s version before relying on it operationally. - It lists tables, not every database access path. Views can bypass RLS by default, and security-definer functions in exposed schemas require careful handling. Review views and functions separately; they are not covered by this table inventory.
- It cannot tell whether a rule matches your product’s access model. It reports metadata, not whether anonymous users, signed-in users, or backend processes should have the access shown. Supabase’s Advisor guidance says to compare findings with the intended schema and access model before changing anything.
- It cannot inspect application code or build artifacts. A database query cannot determine whether an AI builder placed a secret in browser code, a repository, or a deployed bundle.
Review grants and policies together
Grants and RLS policies control different parts of database access. PostgreSQL checks table grants and then RLS policies; adding a policy does not revoke an existing grant. Review grants by role and operation alongside each policy’s command, target roles, and predicates. In particular, confirm that anon, authenticated, and service_role receive only the access the application needs. Supabase describes this sequence in its RLS guide.
Recommended Free Tools
Check keys outside the database query
Publishable keys are designed to appear in shipped client code when RLS and least-privilege access are configured appropriately. Secret and service-role keys bypass RLS and belong only in controlled backend components. Search the app source, repository history, and build or deployment artifacts for secret credentials; this query cannot perform that check. Supabase states in its Securing your data documentation: “Never expose your service role or secret keys on the frontend.” Its API key documentation explains the distinction between publishable and secret keys.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify expected access with tests and Advisor findings
Use Supabase Security Advisor as another input: its checks are available in Studio, MCP, CLI, and the Management API. Review each finding against the intended access model rather than changing configuration solely to clear a warning; some findings may be intentional.
Then test actual behavior for the roles and operations your app uses. Include both cases that should be allowed and cases that should be denied, such as reading, inserting, updating, and deleting where applicable. Supabase recommends database tests that assert expected allow and deny behavior. A catalog inventory is a useful starting point, not a replacement for those behavior tests.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors
