--- title: "Supabase anon key vs service role key: ką jie atveria" description: "Supabase anon (publishable) key naršyklėje saugus tik už RLS, service role (secret) key RLS apeina. Kur kuris priklauso, išbandyta vietinėje aplinkoje." url: "https://madsalt.tech/lt/blog/supabase-anon-key-vs-service-role-key/" author: "Denys Zaichenko" language: "lt" published: 2026-10-25 --- # Supabase anon key vs service role key: ką jie atveria Trumpai Anon key, dabar vadinamas publishable key, skirtas būti viešas: jis atitinka rolę `anon` arba `authenticated`, o ką jis mato, nusprendžia jūsų RLS politikos. Service role key, dabar secret key, atitinka rolę `service_role`, kuri RLS apeina visiškai. Mano vietinėje bandomojoje lentelėje su įjungtu RLS ir be politikos viešasis raktas gavo 0 eilučių, o secret key visas 3. Publishable key dėkite į naršyklę, secret key laikykite serveryje ir pakeiskite jį, jei jis kada nors buvo išsiųstas vartotojams. Esu Denys, full-stack ir AI inžinierius. Nutekėjęs secret key yra pirmas dalykas, kurio ieškau perimdamas Supabase programą, nes su juo visa kita apsauga yra tik dekoracija. Šiame straipsnyje paaiškinta, ką atveria kiekvienas raktas, su užklausomis, kurias paleidau tai patikrinti. ## Kas yra Supabase anon key? Anon key identifikuoja jūsų programą, o ne vartotoją. Jį neša kiekviena užklausa iš naršyklės ar mobiliosios programos, todėl jis turi būti viešas: bet kas gali jį perskaityti puslapio šaltinyje. Užklausa vien su šiuo raktu vykdoma kaip Postgres rolė `anon`. Kai vartotojas prisijungia per Supabase Auth, tas pats raktas keliauja kartu su vartotojo tokenu, ir užklausa vykdoma kaip `authenticated`. Jūsų RLS politikos rašomos šioms dviem rolėms. Supabase raktus pervadina. [API keys vadovas](https://supabase.com/docs/guides/api/api-keys) naujus vadina publishable (`sb_publishable_…`) ir secret (`sb_secret_…`), o senus JWT pagrįstus `anon` ir `service_role` raktus laiko pasenusiais iki 2026 m. pabaigos. Už jų esančios rolės lieka tos pačios. | Raktas | Senas pavadinimas | Postgres rolė | Ar RLS taikomas? | Kur jis eina | | ------------------------------ | ------------------ | ------------------------------------------------ | ------------------------- | ---------------------------------------------------------------- | | Publishable `sb_publishable_…` | `anon` key | `anon`, arba `authenticated` su vartotojo tokenu | Taip | Naršyklė, mobilioji programa, viskas, ką išsiunčiate vartotojams | | Secret `sb_secret_…` | `service_role` key | `service_role` | Ne, rolė turi `BYPASSRLS` | Tik serveris, Edge Function, cron užduotis | ## Ar saugu atskleisti Supabase anon key? Taip, jei apsaugota kiekviena lentelė, view ir funkcija, kurią jis pasiekia. Pats raktas nesuteikia nieko ypatingo; viską nusprendžia jūsų schemos teisės (grants) ir politikos. Tai patikrinau vietinėje Supabase aplinkoje (CLI 2.109.1, Postgres 17.6) su viena lentele, kurioje buvo trys išgalvoti užsakymai: ![Kokia Postgres rolė tampa kiekvienas raktas. Ir ar jūsų RLS politikos mato užklausą. Publishable key, neprisijungus: Publishable key → rolė anon → RLS politikos taikomos; Publishable key, prisijungus: Publishable key + vartotojo tokenas → rolė authenticated → RLS politikos taikomos; Secret key: Secret key → rolė service_role → RLS praleistas.](https://madsalt.tech/charts/lt/supabase-anon-key-vs-service-role-key.svg) *1 pav. Iš Supabase API keys vadovo, patikrinta vietinėje aplinkoje, 2026 m. spalio 23 d.* | Lentelės būsena | Publishable key | Secret key | | ------------------------------------- | ------------------------------------------------------------------- | --------------- | | RLS išjungtas | Visos 3 eilutės, o įterpimas grąžino `201 Created` | Visos 3 eilutės | | RLS įjungtas, politikos nėra | `[]` | Visos 3 eilutės | | RLS įjungtas, politika `using (true)` | Visos 3 eilutės | Visos 3 eilutės | | Rolė `anon` neturi teisės | `42501 permission denied` su užuomina, nurodančia trūkstamą `GRANT` | Visos 3 eilutės | Taigi publishable key yra tiek pat saugus, kiek jūsų silpniausia lentelė. Lentelę be RLS arba su politika, leidžiančia kiekvieną eilutę, gali skaityti bet kas, atidaręs DevTools. Tai spraga, slypinti už [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), kur 170 iš 1645 Lovable demonstracinių programų atidavė duomenis viešajam raktui. ## Kas yra service role key ir kodėl jis pavojingas? Secret key yra pagrindinis raktas. Jis vykdomas kaip `service_role`, turinti atributą `BYPASSRLS`, todėl jokia jūsų parašyta politika jam niekada netaikoma. Paskutiniame aukščiau pateiktos lentelės stulpelyje jis perskaitė visas tris eilutes kiekvienoje būsenoje. Supabase vadovas išvardija, kur jis turi būti: serveriai, kurie patys atlieka autorizacijos patikras, Edge Function, foninės užduotys ir administravimo įrankiai. Dvi vadovo detalės praktikoje svarbios: - Naujas secret key atmeta užklausas iš naršyklės: Supabase tikrina `User-Agent` ir grąžina `401`. Senas `service_role` JWT tokios patikros neturi, todėl nutekėjęs senas raktas veikia iš bet kur. Mano vietinė aplinka, kurioje tokios vartų patikros nėra, scenarijui su secret key atsakė visomis 3 eilutėmis. - Secret key apeina RLS tik tada, kai užklausa neneša vartotojo tokeno. Su prisijungusio vartotojo tokenu užklausa vykdoma pagal to vartotojo politikas. Edge Function, naudojanti secret key, pati turi tikrinti, kas kreipiasi, ir filtruoti pagal savininką ar įmonę, nes po ja to nedaro niekas. ## Kur rasti raktus? Dashboard atidarykite projekto Connect dialogą URL ir publishable key gauti arba Settings → API Keys visiems raktams, įskaitant senus. Vietoje `supabase start` ir `supabase status` išveda publishable key ir secret key. Laikykite juos aplinkos kintamuosiuose: Next.js tik publishable key gali turėti priešdėlį `NEXT_PUBLIC_`, nes bundler į naršyklę išsiunčia viską su šiuo priešdėliu. ## Ką daryti, jei service role key nutekėjo? Laikykite jį pažeistu: kiekviena eilutė kiekvienoje lentelėje buvo skaitoma ir rašoma kiekvieno, kas jį rado. 1. Sukurkite naują secret key, perkelkite serverius į jį, tada ištrinkite nutekėjusį. Jei nutekėjo senas `service_role` key, išeitis yra perėjimas prie naujų raktų: sukurkite publishable ir secret key, perjunkite programą, tada išjunkite senus raktus skiltyje Settings → API Keys, kur kitaip jie lieka galioti. 2. Ieškokite sukompiliuotame JavaScript ir Git istorijoje `sb_secret_` ir `service_role`. Escape 5600 vibe coding programų skenavimas rado [daugiau nei 400 atskleistų paslapčių](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), dauguma frontend bundle. 3. Peržiūrėkite, kas pasikeitė, kol jis buvo išorėje: nauji vartotojai, rolių pakeitimai, ištrintos eilutės. Nemokamas [Supabase saugos tikrintuvas](https://madsalt.tech/lt/tools/supabase-security-check/) neskaito jūsų frontend, bet skaito tos pačios problemos duomenų bazės pusę: roles, apeinančias RLS, lenteles su išjungtu RLS, politikas, leidžiančias kiekvieną eilutę, ir stulpelius, kurie atrodo jautrūs ir yra skaitomi anoniminių lankytojų. Norint patikrinti, ką jūsų viešasis raktas pasiekia praktikoje, žingsniai pateikti straipsnyje [vibe coding saugos rizikos](https://madsalt.tech/lt/blog/vibe-coding-security-risks/), o pilną sąrašą, kurį paleidžiu programai, rasite mano [Lovable programos saugos sąraše](https://madsalt.tech/lt/blog/lovable-app-security-checklist/). Nesate tikri, kurį raktą siunčia jūsų programa? Mielai pažiūrėsiu ir palyginsiu patirtį. Be pardavimų kalbų. [Susisiekti](https://madsalt.tech/lt/#contact)