--- title: "Supabase anon key vs service role key: mida kumbki avab" description: "Anon (publishable) key on brauseris ohutu ainult RLS-i taga, service role (secret) key jätab RLS-i vahele. Kuhu kumbki kuulub, testitud kohalikul pinul." url: "https://madsalt.tech/et/blog/supabase-anon-key-vs-service-role-key/" author: "Denys Zaichenko" language: "et" published: 2026-10-25 --- # Supabase anon key vs service role key: mida kumbki avab Lühidalt Anon key, mida nüüd kutsutakse publishable key'ks, on mõeldud avalikuks: see vastab rollile `anon` või `authenticated` ja teie RLS-poliitikad otsustavad, mida see näeb. Service role key, nüüd secret key, vastab rollile `service_role`, mis jätab RLS-i täielikult vahele. Minu kohalikul testtabelil, kus RLS oli sees ja poliitikat polnud, sai avalik võti 0 rida ja secret key kõik 3. Pange publishable key brauserisse, hoidke secret key serveris ja vahetage see välja, kui see kunagi välja saadeti. 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](https://supabase.com/docs/guides/api/api-keys) 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: ![Millise Postgresi rolli kumbki võti saab. Ja kas teie RLS-poliitikad päringut näevad. Publishable key, sisse logimata: Publishable key → roll anon → RLS-poliitikad kehtivad; Publishable key, sisse logitud: Publishable key + kasutaja token → roll authenticated → RLS-poliitikad kehtivad; Secret key: Secret key → roll service_role → RLS vahele jäetud.](https://madsalt.tech/charts/et/supabase-anon-key-vs-service-role-key.svg) *Joonis 1. Supabase'i API keys juhendist, kontrollitud kohalikul pinul, 23. oktoober 2026.* | 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](https://mattpalmer.io/posts/2025/05/statement-on-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-Agent`i 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](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), enamik frontendi bundle'ites. 3. Vaadake üle, mis muutus, kui see väljas oli: uued kasutajad, rollimuutused, kustutatud read. Tasuta [Supabase'i turvakontroll](https://madsalt.tech/et/tools/supabase-security-check/) 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](https://madsalt.tech/et/blog/vibe-coding-security-risks/) ja täielik nimekiri, mida rakendusel käivitan, on minu [Lovable'i rakenduse turvanimekirjas](https://madsalt.tech/et/blog/lovable-app-security-checklist/). Pole kindel, millist võtit teie rakendus välja saadab? Vaatan hea meelega ja võrdlen märkmeid. Müügijututa. [Võtke ühendust](https://madsalt.tech/et/#contact)