glossary

Supabase Security Glossary

These pages are built for builders who want clarity, not fear. Use them to understand the terms that show up in scans and audits — and to translate “security concept” into “what to check” and “what to change.”

How to use this Supabase security glossary

This glossary is meant to be practical, not academic.

Each term page includes:

A beginner-friendly definition
Technical depth for builders who want precision
Detection signals (what to check in your own project)
Fix patterns that reduce risk in the real world

If you’re scanning your app, start with terms that match your scan output (public tables, permissive policies, storage exposure, and RPC grants).

High-impact terms to learn first

Admin Panel Client-Only Auth → /glossary/admin-panel-client-auth-only — Admin Panel Client-Only Auth is a Supabase security risk where admin protections live in frontend checks instead of enforceable backend authorization, .
API Cache Leaks Private Data → /glossary/api-cache-private-data-leak — API Cache Leaks Private Data is a Supabase security risk where shared caches return user-specific responses to unauthorized sessions, .
Audit Log Table Publicly Readable → /glossary/audit-log-public-readable — Audit Log Table Publicly Readable is a Supabase security risk where diagnostic or audit tables become queryable by client roles, .
Auth Role Claim Confusion → /glossary/auth-role-claim-confusion — Auth Role Claim Confusion is a Supabase security risk where role mapping is ambiguous and grants unintended privileges to users, .
Billing Webhook Idempotency Gap → /glossary/billing-webhook-idempotency-gap — Billing Webhook Idempotency Gap is a Supabase security risk where billing events are processed multiple times and create inconsistent account states, .
Broad DELETE for Authenticated Role → /glossary/broad-authenticated-delete — Broad authenticated DELETE grants allow any logged-in user to remove rows.
Broad SELECT for Authenticated Role → /glossary/broad-authenticated-select — Broad authenticated SELECT grants let every logged-in user read sensitive tables.
Broad UPDATE for Authenticated Role → /glossary/broad-authenticated-update — Broad authenticated UPDATE grants let every logged-in user change other people’s rows.

The model that prevents most Supabase leaks

A lot of teams try to express complex authorization purely in RLS policies. That can work, but it’s easy to get subtly wrong.

Mockly recommends a safer default for most apps:

Treat the browser as untrusted.
Remove direct access to sensitive tables, RPC, and Storage.
Implement a minimal backend layer that enforces authorization explicitly.
Use RLS as an additional safety gate — not your only line of defense.

What to check in every environment (dev/staging/prod)

Tables with RLS disabled or not forced (especially user/billing/admin tables).
Policies that aren’t bound to user/tenant ownership (scraping risk).
Grants to anon and authenticated on sensitive tables and functions.
Storage buckets that are public or allow listing.
RPC functions that are executable by PUBLIC/anon/authenticated.

Fast SQL checks that catch common exposure signals

You don’t need a full pentest to catch the most common Supabase leaks — but you do need repeatable checks.

Use these as “starter queries” to guide your review (adapt to your schema):

List tables where RLS is disabled or not forced (especially tables with user data).
Inspect pg_policies for policies that don’t bind rows to a user or tenant.
Check grants for anon / authenticated on tables and schemas you consider sensitive.
Enumerate functions with public EXECUTE privileges and review whether they should be server-only.
Review Storage buckets and policies to confirm private buckets + signed URL flows for sensitive files.

Each term page links the concept to the checks and fix patterns that reduce risk without requiring perfect policy logic.

How to get value fast (read → check → fix)

Glossary pages are most useful when they change what you do next.

A simple way to use them:

Pick the term that matches your surface (table, Storage bucket, RPC function, or secret).
Run one detection step from the term page (a direct access test beats guesswork).
Follow cross-links to a template/integration and apply one small fix.
Repeat the same direct access test and confirm it now fails.
Add one drift guard (scan/checklist after migrations) so it stays fixed.

If you skip verification, you’ll end up with “RLS enabled” pages that still leak in practice.

Browse the glossary

Term	What it covers	URL
Admin Panel Client-Only Auth	Admin Panel Client-Only Auth is a Supabase security risk where admin protections live in frontend checks instead of enforceable backend authorization, .	/glossary/admin-panel-client-auth-only
API Cache Leaks Private Data	API Cache Leaks Private Data is a Supabase security risk where shared caches return user-specific responses to unauthorized sessions, .	/glossary/api-cache-private-data-leak
Audit Log Table Publicly Readable	Audit Log Table Publicly Readable is a Supabase security risk where diagnostic or audit tables become queryable by client roles, .	/glossary/audit-log-public-readable
Auth Role Claim Confusion	Auth Role Claim Confusion is a Supabase security risk where role mapping is ambiguous and grants unintended privileges to users, .	/glossary/auth-role-claim-confusion
Billing Webhook Idempotency Gap	Billing Webhook Idempotency Gap is a Supabase security risk where billing events are processed multiple times and create inconsistent account states, .	/glossary/billing-webhook-idempotency-gap
Broad DELETE for Authenticated Role	Broad authenticated DELETE grants allow any logged-in user to remove rows.	/glossary/broad-authenticated-delete
Broad SELECT for Authenticated Role	Broad authenticated SELECT grants let every logged-in user read sensitive tables.	/glossary/broad-authenticated-select
Broad UPDATE for Authenticated Role	Broad authenticated UPDATE grants let every logged-in user change other people’s rows.	/glossary/broad-authenticated-update
Broken Object Level Authorization (BOLA)	Broken Object Level Authorization happens when each object is not validated against the requester, letting attackers read other users’ data.	/glossary/broken-object-level-authorization
Bucket LIST Permission Too Broad	Bucket LIST Permission Too Broad is a Supabase security risk where list permissions expose object inventories that assist targeted abuse, .	/glossary/bucket-list-permission-too-broad
Bulk Export Endpoint Overexposure	Bulk Export Endpoint Overexposure is a Supabase security risk where export APIs allow high-volume extraction without strong authorization and limits, .	/glossary/bulk-export-endpoint-overexposure
Client Role Grants (anon/authenticated)	Client role grants (anon/authenticated) create an API surface, and misusing them exposes data to any client.	/glossary/client-role-grants
CORS Misconfiguration in Edge Functions	CORS Misconfiguration in Edge Functions is a Supabase security risk where permissive CORS allows untrusted origins to trigger privileged flows, .	/glossary/cors-misconfiguration-edge-functions
Cross-Schema Data Exposure	Cross-Schema Data Exposure is a Supabase security risk where objects in unintended schemas become reachable through grants or API exposure settings, .	/glossary/cross-schema-exposure
CSV Import Trusts Client Columns	CSV Import Trusts Client Columns is a Supabase security risk where import flows allow users to overwrite sensitive fields through crafted headers, .	/glossary/csv-import-trusts-client-columns
Data API Custom Schema Misconfiguration	Data API Custom Schema Misconfiguration happens when teams move to a custom exposed schema but leave permissive grants, search paths, or legacy objects that keep data reachable.	/glossary/data-api-custom-schema-misconfiguration
Data API Public Schema Exposure	Data API Public Schema Exposure occurs when sensitive tables remain in exposed schemas, making direct REST or GraphQL access possible with client-side credentials.	/glossary/data-api-public-schema-exposure
Database URL Leaked in Client	Database URL Leaked in Client is a Supabase security risk where database connection details leak into browser bundles and deployment artifacts, .	/glossary/leaked-database-url-in-client
Default Function EXECUTE to PUBLIC	Default Function EXECUTE to PUBLIC is the risk that newly created routines remain callable by broad roles unless explicit revokes/default privileges are applied.	/glossary/default-function-execute-to-public
Default Privilege Drift	Default privilege drift happens when inherited grants become permissive, exposing every new object you create.	/glossary/default-privilege-drift

FAQ

Do these glossary pages apply to every Supabase app?

They’re written to cover the most common exposure patterns across Supabase apps, but you should always validate in your own project because grants, policies, and storage settings vary by schema and environment.

What’s the fastest way to use this glossary during a security review?

Start with the terms that map to your highest-risk surfaces: public tables, permissive policies, storage exposure, and public RPC. Use the detection checklist on each term page to confirm the issue is real, then apply the fix pattern.

How do I know the fix is real (not just the UI)?

Verify via direct access tests and keep a drift checklist after migrations. If you can’t prove a boundary is enforced by the database/Storage/RPC (not the UI), assume it can regress.

Next step

If you want the glossary to point at your real risks, run a scan in Mockly and follow the linked term pages to validate and fix exposure.

See pricing Back to landing