Supabase
Security & compliance
Auth & service-role key safety
The key that bypasses RLS, and everywhere it reaches.
Overview
The service-role key ignores Row-Level Security by design. This check follows it through your repo — which clients are built with it, which of those run in the browser, and which server queries use it without re-applying the tenant filter that RLS would have applied.
What it looks for
- Service-role keys reachable from client-side or browser code
- Service-role queries with no tenant or owner filter
- Anon-key clients performing privileged writes
- user_id read from the request body instead of the verified JWT
- Supabase queries in route handlers with no auth check before them
Why it matters
A service-role key in a client bundle is a full database read to anyone who opens devtools, and no policy will stop it. On the server the risk is quieter: every service-role query is unfiltered unless you filter it yourself, so one missing WHERE returns the whole table.
Rules in this check
| What it reports | Fix path |
|---|---|
| Service-role key exposed in client-side code — full RLS bypass | Pull request |
| Service-role client queries a table with no tenant filter | Pull request |
| Anon-key client used for a privileged write | Guide |
| IDOR risk: user_id from request body used in Supabase query without JWT verification | Pull request |
| No auth check before a Supabase query in a route handler | Guide |
How the fixes arrive
Pull requestLow-risk changes arrive as a pull request on a lumioguard branch, with a breakage analysis attached. You review and merge it.
GuideChanges only you can make safely arrive as a step-by-step guide you can follow yourself or hand to your coding agent.
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.