Supabase anon key vs service role key: mida kumbki avab

Olen Denys, full-stack- ja AI-insener. Lekkinud secret key on esimene asi, mida otsin, kui Supabase’i rakenduse üle võtan, sest sellega on kõik muu kaitse kaunistus. See artikkel selgitab, mida kumbki võti avab, koos päringutega, mida kontrollimiseks tegin.

Mis on Supabase anon key?

Anon key tuvastab teie rakenduse, mitte teie kasutaja. Iga päring brauserist või mobiilirakendusest kannab seda, seega peab see olema avalik: igaüks saab selle lehe lähtekoodist lugeda. Päring ainult selle võtmega jookseb Postgresi rollina anon. Kui kasutaja logib Supabase Auth’i kaudu sisse, liigub sama võti koos kasutaja tokeniga ja päring jookseb rollina authenticated. Teie RLS-poliitikad on kirjutatud nendele kahele rollile.

Supabase nimetab võtmeid ümber. API keys guide kutsub uusi publishable (sb_publishable_…) ja secret (sb_secret_…) ning kuulutab vanad JWT-põhised anon ja service_role võtmed aegunuks 2026. aasta lõpuks. Nende taga olevad rollid jäävad samaks.

Võti	Vana nimi	Postgresi roll	Kas RLS kehtib?	Kuhu see läheb
Publishable sb_publishable_…	anon key	anon või kasutaja tokeniga authenticated	Jah	Brauser, mobiilirakendus, kõik, mis välja saadate
Secret sb_secret_…	service_role key	service_role	Ei, rollil on BYPASSRLS	Ainult server, Edge Function, cron-töö

Kas Supabase anon key avalikustamine on ohutu?

Jah, kui iga tabel, view ja funktsioon, mida see kätte saab, on kaitstud. Võti ise ei anna midagi erilist; kõik otsustavad teie skeemi õigused (grants) ja poliitikad. Kontrollisin seda kohalikul Supabase’i pinul (CLI 2.109.1, Postgres 17.6) ühe tabeliga, kus oli kolm võltstellimust:

Tabeli olek	Publishable key	Secret key
RLS väljas	Kõik 3 rida ja lisamine tagastas 201 Created	Kõik 3 rida
RLS sees, poliitikat pole	[]	Kõik 3 rida
RLS sees, poliitika using (true)	Kõik 3 rida	Kõik 3 rida
Rollil anon õigust pole	42501 permission denied, vihjega, mis nimetab puuduva GRANT-i	Kõik 3 rida

Seega on publishable key täpselt nii ohutu kui teie nõrgim tabel. Tabel ilma RLS-ita või poliitikaga, mis lubab iga rea, on loetav igaühele, kes avab DevTools’i. See on auk CVE-2025-48757 taga, kus 170 Lovable’i näiterakendust 1645-st andis andmeid avalikule võtmele.

Mis on service role key ja miks see on ohtlik?

Secret key on peavõti. See jookseb rollina service_role, millel on atribuut BYPASSRLS, seega ükski teie kirjutatud poliitika sellele kunagi ei kehti. Ülaltoodud tabeli viimases veerus luges see kõik kolm rida igas olekus. Supabase’i juhend loetleb, kuhu see kuulub: serverid, mis teevad ise autoriseerimiskontrolle, Edge Function’id, taustatööd ja admin-tööriistad. Kaks juhendi detaili loevad praktikas:

• Uus secret key keeldub brauseri päringutest: Supabase vastendab User-Agenti ja tagastab 401. Vanal service_role JWT-l sellist kontrolli pole, seega töötab lekkinud vana võti kõikjalt. Minu kohalik pin, kus sellist lüüsikontrolli pole, vastas skriptile secret key’ga kõigi 3 reaga.
• Secret key jätab RLS-i vahele ainult siis, kui päring ei kanna kasutaja tokenit. Sisseloginud kasutaja tokeniga jookseb päring selle kasutaja poliitikate all.

Edge Function, mis secret key’t kasutab, peab ise kontrollima, kes helistab, ja filtreerima omaniku või ettevõtte järgi, sest selle all ei tee seda miski.

Kust võtmeid leida?

Dashboardis avage projekti Connect dialoog URL-i ja publishable key jaoks või Settings → API Keys kõigi võtmete jaoks, sealhulgas vanade. Lokaalselt prindivad supabase start ja supabase status publishable key ja secret key. Hoidke neid keskkonnamuutujates: Next.js-is võib eesliidet NEXT_PUBLIC_ kanda ainult publishable key, sest bundler saadab kõik selle eesliitega brauserisse.

Mida teha, kui service role key lekkis?

Käsitlege seda kompromiteeritud võtmena: iga rida igas tabelis oli loetav ja kirjutatav igaühele, kes selle leidis.

1. Looge uus secret key, viige serverid sellele üle, seejärel kustutage lekkinud võti. Kui leke oli vana service_role key, on väljapääs üleminek uutele võtmetele: looge publishable ja secret key, lülitage rakendus ümber, seejärel keelake vanad võtmed kohas Settings → API Keys, kus need muidu jäävad kehtima.
2. Otsige ehitatud JavaScriptist ja Giti ajaloost sb_secret_ ja service_role. Escape’i 5600 vibe coding’uga loodud rakenduse skaneerimine leidis üle 400 paljastatud saladuse, enamik frontendi bundle’ites.
3. Vaadake üle, mis muutus, kui see väljas oli: uued kasutajad, rollimuutused, kustutatud read.

Tasuta Supabase’i turvakontroll ei loe teie frontendi, kuid loeb sama probleemi andmebaasipoolt: rollid, mis jätavad RLS-i vahele, tabelid RLS-iga väljas, poliitikad, mis lubavad iga rea, ja veerud, mis näevad tundlikud välja ning on anonüümsetele külastajatele loetavad. Et kontrollida, mida teie avalik võti praktikas kätte saab, on sammud artiklis vibe coding turvariskid ja täielik nimekiri, mida rakendusel käivitan, on minu Lovable’i rakenduse turvanimekirjas.