Skip to contentLockpick
How it worksPricingDocs

Read

  • BlogPlain answers to common security questions
  • GuidesStep by step fixes for common setups
  • Security checksEvery check we run, explained

Learn

  • Learn with PickTwo-minute lessons on how sites get attacked
  • Lockpick for ClaudeCheck sites from Claude and other assistants
  • GlossaryThe words we use, in plain words

Company

  • ChangelogWhat changed, newest first
  • StatusWhether scans are running right now
  • Security and trustHow we check and what we never do
Sign inCheck it
Blog

Supabase anon key vs service role key, which one can be in your frontend

By Mark KashefPublished October 8, 2026

The anon key, now called the publishable key, can be in your frontend. The service_role key, now called the secret key, can never be. Supabase says anyone can read the publishable key, so it only reaches what Row Level Security allows. Supabase says the secret key bypasses Row Level Security, so it must never leave your control.

What can each key reach?

KeyPostgres roleRow level securityBelongs in
anon or publishableanon, or authenticated once someone signs inAppliesBrowser, mobile app, frontend code
service_role or secretservice_roleSkippedServer code and Edge Functions only

Supabase's newer secret keys do not work in a browser at all, and Supabase answers such a request with HTTP 401 Unauthorized. The older service_role key has no such check. Supabase is deprecating the anon and service_role keys by the end of 2026 in favour of publishable and secret keys.

Curious what your site shows from outside? The quick check is free and needs no account.

Check it

The service role key shipped. What now?

  1. Rotate it in the Supabase dashboard, because anyone who saw the bundle could already have used it.
  2. Move every call that used it into server code or an Edge Function.
  3. Use the publishable key in the frontend, with row level security on every table it reaches.
  4. Deploy and check the live site again.

Does a working anon key mean your data is safe?

No. The anon key is only as safe as your policies. Atlas, our example app at atlas.example, ships its publishable key on purpose and relies on policies for each table. A missing grant returns a permission error, whereas a policy that matches no rows returns an empty result. So neither an empty answer nor a permission error proves that row level security is on. Check each table's grants and policies in the dashboard instead.

Questions people ask

Is it a problem that my anon key is visible in the browser?

No. It is designed to be public. What matters is that every table it can reach has row level security and policies that match who should read it.

How do I tell which key is in my bundle?

Newer keys start with sb_publishable or sb_secret. Older keys are long tokens, so check which key your client code passes to createClient and compare it with the dashboard.

See what your site shows from outside

A quick check reads your homepage the way a visitor would and gives you a score. No account needed.

Check your site

Related pages

  • Supabase security checklist for apps built with AI
  • Lovable security checklist for a live app
  • API keys in your JavaScript bundle, how they get there and what to do

Sources

  1. API keys Supabase docs, read on October 6, 2026

About the author

Mark Kashef, Founder of Lockpick

I'm Mark, and I build Lockpick. I write these pages, and each one is checked against its sources before it goes live. The Updated date changes only when the page itself does.

Lockpick
PricingMethodologyDocsBlogGuidesSecurity checksLearn with PickSecurity and trustLockpick for ClaudeChangelogStatusFacts for AI assistants

Lockpick is a security scanner for vibe-coded apps. It checks what your live site exposes and what a GitHub repo or AI skill would do before you install it, then gives you a fix prompt for Lovable, Bolt, Replit, Cursor or Claude Code.

Lockpick assesses public pages you are authorized to test, and public GitHub code it never runs.

© 2026 LockpickTermsPrivacyContactSign in