Supabase anon key vs service role key: hva hver åpner

Jeg er Denys, fullstack- og AI-ingeniør. En lekket secret key er det første jeg leter etter når jeg overtar en Supabase-app, for med den er alle andre vern bare pynt. Denne artikkelen forklarer hva hver nøkkel åpner, med forespørslene jeg kjørte for å sjekke det.

Hva er Supabase anon key?

Anon key identifiserer appen din, ikke brukeren din. Hver forespørsel fra en nettleser eller mobilapp har den med, så den må være offentlig: alle kan lese den i sidekilden. En forespørsel med bare denne nøkkelen kjører som Postgres-rollen anon. Når en bruker logger inn gjennom Supabase Auth, følger den samme nøkkelen med brukerens token, og forespørselen kjører som authenticated. RLS-policyene dine er skrevet for disse to rollene.

Supabase endrer navn på nøklene. Guiden om API-nøkler kaller de nye publishable (sb_publishable_…) og secret (sb_secret_…), og avvikler de gamle JWT-baserte nøklene anon og service_role innen utgangen av 2026. Rollene bak dem forblir de samme.

Nøkkel	Gammelt navn	Postgres-rolle	Gjelder RLS?	Hvor den hører hjemme
Publishable sb_publishable_…	anon key	anon, eller authenticated med brukertoken	Ja	Nettleser, mobilapp, alt du sender ut
Secret sb_secret_…	service_role key	service_role	Nei, rollen har BYPASSRLS	Bare server, Edge Function, cron-jobb

Er det trygt å eksponere Supabase anon key?

Ja, hvis hver tabell, view og funksjon den når er beskyttet. Selve nøkkelen gir ikke noe spesielt; tilgangene og policyene i skjemaet ditt avgjør alt. Jeg sjekket dette på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6) med én tabell med tre falske bestillinger:

Tabelltilstand	Publishable key	Secret key
RLS av	Alle 3 rader, og en insert ga 201 Created	Alle 3 rader
RLS på, ingen policy	[]	Alle 3 rader
RLS på, policy using (true)	Alle 3 rader	Alle 3 rader
Ingen tilgang for anon	42501 permission denied, med et hint som nevner den manglende GRANT	Alle 3 rader

Publishable key er altså akkurat så trygg som den svakeste tabellen din. En tabell uten RLS, eller med en policy som slipper inn alle rader, kan leses av alle som åpner DevTools. Det er hullet bak CVE-2025-48757, der 170 av 1 645 Lovable-showcase-apper ga data til den offentlige nøkkelen.

Hva er service role key, og hvorfor er den farlig?

Secret key er hovednøkkelen. Den kjører som service_role, som har attributtet BYPASSRLS, så ingen policy du skriver gjelder noensinne for den. I siste kolonne i tabellen over leste den alle tre radene i hver tilstand. Supabases guide lister hvor den hører hjemme: servere som kjører egne autorisasjonssjekker, Edge Functions, bakgrunnsjobber og admin-verktøy. To detaljer fra guiden har betydning i praksis:

• Den nye secret key avviser forespørsler fra nettleser: Supabase sjekker User-Agent og svarer 401. Den gamle service_role-JWT-en har ingen slik sjekk, så en lekket gammel nøkkel virker fra hvor som helst. Min lokale stack, som ikke har noen slik sjekk i gatewayen, svarte et skript med secret key med alle 3 rader.
• En secret key omgår RLS bare når forespørselen ikke har noe brukertoken. Med en innlogget brukers token kjører forespørselen under den brukerens policyer.

En Edge Function som bruker secret key må selv sjekke hvem som kaller og filtrere på eier eller selskap, for ingenting under den gjør det.

Hvor finner du nøklene?

I Dashboard åpner du Connect-dialogen i prosjektet for URL-en og publishable key, eller Settings → API Keys for alle nøklene, de gamle inkludert. Lokalt skriver supabase start og supabase status ut en publishable key og en secret key. Hold dem i miljøvariabler: i Next.js er det bare publishable key som kan ha prefikset NEXT_PUBLIC_, fordi bundleren sender alt med det prefikset til nettleseren.

Hva gjør du hvis service role key har lekket?

Behandle den som kompromittert: hver rad i hver tabell kunne leses og skrives av den som fant den.

1. Lag en ny secret key, flytt serverne dine over til den, og slett deretter den lekkede. Hvis lekkasjen var en gammel service_role-nøkkel, er veien ut overgangen til de nye nøklene: lag en publishable key og en secret key, bytt appen over, og deaktiver så de gamle nøklene i Settings → API Keys, der de ellers forblir gyldige.
2. Søk i den bygde JavaScript-en og i Git-historikken etter sb_secret_ og service_role. Escapes skanning av 5 600 vibe-kodede apper fant over 400 eksponerte hemmeligheter, de fleste i frontend-bundler.
3. Gå gjennom hva som endret seg mens den var ute: nye brukere, rolleendringer, slettede rader.

Den gratis Supabase-sikkerhetssjekken leser ikke frontend, men den leser databasesiden av samme problem: roller som omgår RLS, tabeller med RLS av, policyer som slipper inn alle rader og kolonner som ser sensitive ut og kan leses av anonyme besøkende. Hvordan du sjekker hva den offentlige nøkkelen når i praksis, står i vibe coding security risks, og hele listen jeg kjører på en app, står i sikkerhetsjekklisten min for Lovable-apper.