Is my Supabase anon key safe to expose?

1. 01sb_publishable_…: current public key. Intended for browsers and other public clients.
2. 02Legacy anon: public JWT key. Its permissions still depend on grants and database policies.
3. 03sb_secret_…: server-only secret. Elevated access bypasses RLS; never publish it.
4. 04Legacy service_role: server-only JWT key. It also bypasses RLS; never put it in client code.

Legacy keys can look alike because both are JWTs. Confirm the key type in your project's API Keys settings. Do not paste credentials into an online decoder, a report, or a support conversation.

If a server-only key leaked, replace or revoke the affected credential through Supabase's key controls. Remove it from client code, redeploy, and review logs for unexpected access. Creating new-style keys does not disable the legacy keys automatically.

New secret keys reject browser requests, but other clients can still use a leaked value. That browser restriction is not a reason to leave a secret exposed. Our exposed-key guide explains the difference between replacement and remediation.

In your Supabase dashboard, find Data API and its Exposed schemas list. The default includes public. Replace the schema list in each query below with your actual exposed schemas. Run these queries in your own project's SQL Editor.

These queries read database metadata only. They do not retrieve customer rows or change permissions. Dashboard-created tables normally enable RLS; SQL-created tables need explicit enabling. Check the state rather than assuming a default.

WITH exposed(schema_name) AS (VALUES ('public')),
clients(role_name) AS (VALUES ('anon'), ('authenticated'))
SELECT
  n.nspname AS schema_name,
  c.relname AS object_name,
  c.relkind AS object_kind,
  r.role_name,
  has_schema_privilege(r.role_name, n.oid, 'USAGE') AS schema_access,
  c.relrowsecurity AS rls_enabled,
  c.relowner::regrole AS object_owner,
  pg_has_role(r.role_name, c.relowner, 'USAGE') AS inherits_owner,
  c.reloptions AS object_options,
  ARRAY(
    SELECT privilege
    FROM unnest(ARRAY[
      'SELECT', 'INSERT', 'UPDATE', 'DELETE',
      'TRUNCATE', 'REFERENCES', 'TRIGGER'
    ]) AS privilege
    WHERE has_table_privilege(r.role_name, c.oid, privilege)
  ) AS table_privileges,
  ARRAY(
    SELECT privilege
    FROM unnest(ARRAY['SELECT', 'INSERT', 'UPDATE', 'REFERENCES']) AS privilege
    WHERE has_any_column_privilege(r.role_name, c.oid, privilege)
  ) AS privileges_on_any_column
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN exposed e ON e.schema_name = n.nspname
CROSS JOIN clients r
WHERE c.relkind IN ('r', 'p', 'v', 'm')
ORDER BY schema_name, object_name, role_name;

Object kinds are r for tables, p for partitioned tables, v for views, and m for materialized views. The privilege checks include inherited grants and grants to PUBLIC. Column-only grants appear separately, so an empty table-privilege list is not automatically safe.

1. 01Review private tables with schema access, read or write privileges, and disabled RLS first.
2. 02Review unexpected write privileges. RLS constrains rows; it does not restrict columns or cover TRUNCATE.
3. 03Review client ownership or inherited ownership. Table owners normally bypass RLS unless it is forced.
4. 04Review granted views without security_invoker=true. Ordinary views can use owner privileges and bypass underlying RLS.

PostgreSQL 15 and later support security_invoker=true for ordinary views. Materialized views need their own access review; do not treat that setting as their protection.

SELECT schemaname, tablename, policyname, permissive,
       roles, cmd, qual AS using_expression, with_check
FROM pg_policies
WHERE schemaname IN ('public')
ORDER BY schemaname, tablename, policyname;

SELECT rolname, rolsuper, rolbypassrls, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname IN ('anon', 'authenticated');

For private data, examine which roles each policy allows and how ownership is enforced. USING (true) allows every row for the applicable operation and roles; it is only appropriate for intentionally shared data. Permissive policies combine with OR, so one broad policy can undermine a narrow one.

Enabled RLS with no applicable policy defaults to denying ordinary row access. Missing write policies do not automatically allow writes. Review WITH CHECK for inserted and updated rows. Elevated client-role attributes are warning signs, not normal requirements for browser access.

Public-key requests without a signed-in token use anon. Requests with a valid user token use authenticated, including Supabase Auth anonymous sign-ins. Testing only the signed-out case misses what another customer can access after signing in.

1. 01Use staging where possible. Create 2 disposable accounts you control and a synthetic private record owned by account B.
2. 02As B, confirm the exact record loads through the real API. Keep a distinctive synthetic marker, not customer data.
3. 03As A, request that same record directly. Confirm B's private marker and fields are absent.
4. 04Repeat while signed out, then confirm A's own record still loads. A broken session or outage is not proof of isolation.
5. 05Repeat after the policy change. Record the endpoint, identity used, expected behavior, and actual response without saving session tokens.

Only test your own app or an app you have explicit permission to assess. A denied request can mean a policy worked, a login expired, or the app stopped responding. The owner-account control distinguishes those outcomes. For write testing, use an explicitly authorized non-production environment.

Follow the Supabase RLS checklist for policy review. Also inspect response columns: limiting rows does not prevent unnecessary private fields from reaching an otherwise authorized caller.

A browser-visible public key identifies a Supabase integration. It cannot tell a passive scanner whether every ownership policy holds. Preflight checks public exposures; it does not inspect your SQL policies or verify account isolation.

You can run ShipSafe's free Preflight without a login or card. The full authorized assessment remains unavailable for purchase while its delivery is being completed. A clean public result is not a clean bill of health for your database.

Sources: Supabase's official API-key documentation, RLS and view guidance, Data API permissions, and exposed-schema configuration.