Supabase + RLS
Pathrule2 Rules • 2 Memories • 1 Skill
Rules, memories, and a review skill for Supabase Postgres projects that take Row Level Security seriously. Pre-scoped to your supabase directory so your AI assistant enforces RLS, keeps the service role out of clients, and follows a disciplined migration flow.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
supabase-rls-review
supabase/
RLS enabled on every table, deny by default
User JWT only, never the service role in client paths
Access via a single has_access helper
migrations/
Migration workflow
Rules
2RLS enabled on every table, deny by default/supabasehighstrictNo table ships without Row Level Security and explicit policies.
| 1 | Every table in a public-facing schema has Row Level Security enabled. |
| 2 | |
| 3 | - Start from deny by default and add narrow policies per operation (`select`, `insert`, `update`, `delete`). |
| 4 | - A migration that creates a table without enabling RLS and adding policies is incomplete and must not merge. |
User JWT only, never the service role in client paths/supabasehighstrictThe service role key bypasses RLS and must stay server-side.
| 1 | The service role key bypasses RLS entirely, so it stays server-side. |
| 2 | |
| 3 | - Client code and edge functions acting on behalf of a user use the user's JWT, so RLS applies. |
| 4 | - The service role key is only for trusted server-side jobs that intentionally need it. |
| 5 | - Never ship it to a browser or derive it from a client request. |
Memories
2Access via a single has_access helper/supabaseCentralize the access check in one SQL function reused by policies.
| 1 | Express membership and ownership in one `SECURITY DEFINER` helper (for example `has_workspace_access(user_id, workspace_id)`) and reference it from RLS policies across tables. |
| 2 | |
| 3 | - Keeps the access model in one place. |
| 4 | - Makes policies readable. |
| 5 | - Avoids subtly different inline checks that drift apart over time. |
Migration workflow/supabase/migrationsForward-only, reviewed SQL with RLS and types regenerated.
| 1 | Migrations are forward-only and timestamped. |
| 2 | |
| 3 | - Each one is self-contained and idempotent where practical. |
| 4 | - Enable RLS and add policies in the same migration as the table. |
| 5 | - Regenerate TypeScript types after a schema change. |
| 6 | - Never edit a migration that already ran in a shared environment; add a new one. |
Skills
1supabase-rls-review/rootChecklist for reviewing a Supabase schema or migration change.
| 1 | --- |
| 2 | name: supabase-rls-review |
| 3 | description: Review a Supabase migration or schema change for RLS correctness and safety. |
| 4 | --- |
| 5 | |
| 6 | # Supabase RLS review |
| 7 | |
| 8 | - [ ] RLS is enabled on every new table |
| 9 | - [ ] Policies exist per operation and deny by default |
| 10 | - [ ] Policies use the shared access helper, not ad hoc inline checks |
| 11 | - [ ] No service role key is reachable from client or per-request code |
| 12 | - [ ] Indexes back the columns used in policy predicates |
| 13 | - [ ] TypeScript types regenerated after the schema change |
| 14 | - [ ] Migration is forward-only and does not edit an already-applied file |
Why this pattern
Postgres tables ship without Row Level Security, or the service role key sneaks into client paths, leaving data open to anyone.
Built for teams building on Supabase Postgres with multi-tenant or per-user data.
Keeps your assistant from:
- Creating a table without RLS enabled and policies
- Using the service role key where the user's JWT belongs
- Ad hoc access checks that drift apart across tables
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09