# Supabase RLS checker. Catch six common SQL risks.

Paste PostgreSQL table and policy definitions for a static analysis with suggested fixes — free, no sign-up. SQL stays in your browser; this does not replace a security review.

Page: https://saascode.ai/tools/supabase-rls-checker

## How to use

1. Paste a schema snapshot including CREATE TABLE, RLS enable statements, CREATE POLICY and function definitions, under 200 KB.
2. Mark all tables multi-tenant if that describes your application, then Check RLS.
3. Review findings and suggested fixes. Confirm intentional public access, tenant boundaries, helper functions and grants in a separate security review and test database.

## Scope

Static analysis only; suggested fixes require review. It does not replace a security review or test the live database.

## References

- [Supabase row level security](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [Supabase database functions: security definer](https://supabase.com/docs/guides/database/functions)

## Build your SaaS

[Explore SaaSCode Base and its RLS foundation](https://saascode.ai/free)

## Related tools

- [Supabase JWT decoder](https://saascode.ai/tools/jwt-decoder)
- [PostgreSQL SQL formatter](https://saascode.ai/tools/sql-formatter)
- [Next.js env & secrets generator](https://saascode.ai/tools/env-generator)
- [All free tools](https://saascode.ai/tools)

## FAQ

### Is this free, and do I need an account?

Free, no sign-up. Calculations and analysis run in your browser. SQL and usage inputs are never uploaded to a processing API. Analytics record only the tool and action; public source data comes from the site.

### Which six patterns are checked?

Tables without ENABLE ROW LEVEL SECURITY; tables without a CREATE POLICY; policies querying their own protected table; USING (true) on apparent user data; likely multi-tenant tables without organization_id; and SECURITY DEFINER functions without explicit SET search_path.

### Does this execute SQL or connect to Supabase?

No. Lexical static analysis runs locally. It ignores comments and quoted string contents when recognizing outer SQL statements, and leaves procedural or dynamic SQL bodies opaque. No SQL processing API or database connection is used.

### Does zero findings mean my policies are secure?

No. The tool does not resolve your live schema, grants, role behavior, helper-function recursion, CTE name shadowing, views or runtime permissions. Test authenticated, anonymous and cross-tenant access and obtain a security review.

### How are user data and tenancy identified?

User, owner, member, creator and email columns or auth.uid() references suggest user data. Tenant, workspace, team and account keys or organization references suggest tenancy. You can explicitly treat all pasted tables as multi-tenant. These heuristics may overflag or miss a boundary.

### Is every missing policy or alternate tenant key a defect?

No. Default denial with no policies can be deliberate, and another verified tenant key may be correct. Findings describe what is absent from this pasted snapshot, not proof of a production vulnerability. Review each fix before applying it.

### Why pin search_path on SECURITY DEFINER functions?

Such a function runs with its owner's privileges. A fixed trusted search path and schema-qualified references help avoid object substitution. Review EXECUTE grants as well; adding search_path alone is not a full safety check.