The important distinction
Publishable client configuration is public by design.
A Supabase project URL and current publishable key—or a legacy anon key—can legitimately appear in a browser application. Security must come from grants, Row Level Security, authenticated user context, and storage policies rather than from hiding a public client identifier.
Secret keys and legacy service-role keys are different: they belong on the server and can bypass Row Level Security. SiteGuardrail separates these categories in its wording and redacts secret-looking evidence.
How to read a focused result
A detected Supabase signal may be informational.
Normal on its own. Confirm RLS, grants, storage policies, and intended public access.
High priority. Remove it from the browser, rotate it, and review access.
Review the named realtime, redirect, or public-storage context manually.
None was observed in completed public coverage; this says nothing about private policies.
Supabase hardening
Protect the data layer that sits behind public client configuration.
- Use a publishable key for browser clients; keep secret and service-role keys server-side.
- Enable RLS on every exposed table and write least-privilege policies for anon and authenticated roles.
- Review grants as well as RLS; both determine what the Data API can reach.
- Apply intended policies to storage buckets and objects.
- Constrain auth redirect allowlists and avoid user-controlled redirect targets.
- Rotate any privileged key that reached a public bundle or file.
Limitations
A passive website scan cannot audit your database policies.
SiteGuardrail does not authenticate as users, enumerate tables, test RLS policies, validate storage permissions, or attempt to use detected credentials. A clean public scan is not evidence that Supabase grants, RLS, functions, auth flows, or buckets are secure. Use Supabase's dashboard security tooling and policy tests as separate controls. SiteGuardrail is independent and is not affiliated with Supabase.