Supabase anon key vs service role key: ką jie atveria

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 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:

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, 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ų, 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 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, o pilną sąrašą, kurį paleidžiu programai, rasite mano Lovable programos saugos sąraše.