Supabase anon key vs service role key: mitä kumpikin avaa

Olen Denys, full-stack- ja tekoäly-insinööri. Vuotanut secret key on ensimmäinen asia, jota etsin ottaessani haltuun Supabase-sovelluksen, koska sen kanssa kaikki muut suojat ovat pelkkää koristetta. Tässä artikkelissa selitän, mitä kumpikin avain avaa, ja kerron pyynnöt, joilla sen tarkistin.

Mikä on Supabase anon key?

Anon key tunnistaa sovelluksesi, ei käyttäjääsi. Jokainen selaimen tai mobiilisovelluksen pyyntö kuljettaa sitä mukanaan, joten sen on oltava julkinen: kuka tahansa voi lukea sen sivun lähdekoodista. Pyyntö, jossa on vain tämä avain, ajetaan Postgres-roolilla anon. Kun käyttäjä kirjautuu sisään Supabase Authin kautta, sama avain kulkee käyttäjän tokenin mukana ja pyyntö ajetaan roolilla authenticated. RLS-politiikkasi on kirjoitettu näille kahdelle roolille.

Supabase nimeää avaimet uudelleen. API-avainopas kutsuu uusia publishable- (sb_publishable_…) ja secret-avaimiksi (sb_secret_…) ja poistaa vanhat JWT-pohjaiset anon- ja service_role-avaimet käytöstä vuoden 2026 loppuun mennessä. Niiden takana olevat roolit pysyvät samoina.

Avain	Vanha nimi	Postgres-rooli	Koskeeko RLS?	Minne se kuuluu
Publishable sb_publishable_…	anon key	anon, tai authenticated käyttäjätokenin kanssa	Kyllä	Selain, mobiilisovellus, kaikki mitä julkaiset
Secret sb_secret_…	service_role key	service_role	Ei, roolilla on BYPASSRLS	Vain palvelin, Edge Function, cron-ajo

Onko Supabase anon keyn paljastaminen turvallista?

Kyllä, jos jokainen taulu, view ja funktio, johon se yltää, on suojattu. Avain itsessään ei anna mitään erityistä; skeemasi oikeudet ja politiikat ratkaisevat kaiken. Tarkistin tämän paikallisella Supabase-stackilla (CLI 2.109.1, Postgres 17.6) yhdellä kolmen tekaistun tilauksen taululla:

Taulun tila	Publishable key	Secret key
RLS pois	Kaikki 3 riviä, ja insert palautti 201 Created	Kaikki 3 riviä
RLS päällä, ei politiikkaa	[]	Kaikki 3 riviä
RLS päällä, politiikka using (true)	Kaikki 3 riviä	Kaikki 3 riviä
Ei oikeutta roolille anon	42501 permission denied, vihjeellä, joka nimeää puuttuvan GRANT-lauseen	Kaikki 3 riviä

Publishable key on siis täsmälleen yhtä turvallinen kuin heikoin taulusi. Taulun, jossa ei ole RLS:ää tai jossa politiikka päästää jokaisen rivin, voi lukea kuka tahansa, joka avaa DevToolsin. Se on aukko CVE-2025-48757:n takana, jossa 170 Lovablen 1 645 esittelysovelluksesta tarjosi dataa julkiselle avaimelle.

Mikä service role key on, ja miksi se on vaarallinen?

Secret key on pääavain. Se ajetaan roolilla service_role, jolla on BYPASSRLS-attribuutti, joten mikään kirjoittamasi politiikka ei koskaan koske sitä. Yllä olevan taulukon viimeisessä sarakkeessa se luki kaikki kolme riviä jokaisessa tilassa. Supabasen opas listaa, minne se kuuluu: palvelimille, jotka tekevät omat valtuutustarkistuksensa, Edge Functioneihin, taustatöihin ja ylläpitotyökaluihin. Kaksi oppaan yksityiskohtaa on käytännössä tärkeää:

• Uusi secret key torjuu selainpyynnöt: Supabase vertaa User-Agent-otsikkoa ja palauttaa 401. Vanhalla service_role-JWT:llä ei ole tällaista tarkistusta, joten vuotanut vanha avain toimii mistä tahansa. Paikallinen stackini, jossa ei ole tällaista gateway-tarkistusta, vastasi secret keyllä ajettuun skriptiin kaikilla 3 rivillä.
• Secret key ohittaa RLS:n vain, kun pyynnössä ei ole käyttäjätokenia. Kirjautuneen käyttäjän tokenilla pyyntö ajetaan kyseisen käyttäjän politiikoilla.

Edge Functionin, joka käyttää secret keytä, on itse tarkistettava, kuka kutsuu, ja suodatettava omistajan tai yrityksen mukaan, koska mikään sen alla ei sitä tee.

Mistä avaimet löytyvät?

Dashboardissa avaa projektin Connect-dialogi URL-osoitetta ja publishable keytä varten tai Settings → API Keys kaikkia avaimia, vanhat mukaan lukien, varten. Paikallisesti supabase start ja supabase status tulostavat publishable keyn ja secret keyn. Pidä ne ympäristömuuttujissa: Next.js:ssä vain publishable keyllä saa olla etuliite NEXT_PUBLIC_, koska bundleri lähettää kaiken tuolla etuliitteellä olevan selaimelle.

Mitä teet, jos service role key vuosi?

Pidä sitä vaarantuneena: jokaisen taulun jokaisen rivin pystyi lukemaan ja kirjoittamaan se, joka avaimen löysi.

1. Luo uusi secret key, siirrä palvelimesi käyttämään sitä ja poista sitten vuotanut. Jos vuoto oli vanha service_role-avain, tie ulos on siirtyminen uusiin avaimiin: luo publishable key ja secret key, vaihda sovellus niihin ja poista sitten vanhat avaimet käytöstä kohdassa Settings → API Keys, jossa ne muuten pysyvät voimassa.
2. Etsi rakennetusta JavaScriptistä ja Git-historiasta merkkijonoja sb_secret_ ja service_role. Escapen 5 600 vibe coding -sovelluksen skannaus löysi yli 400 paljastunutta salaisuutta, useimmat frontend-bundleista.
3. Käy läpi, mitä muuttui sinä aikana, kun avain oli ulkona: uudet käyttäjät, roolimuutokset, poistetut rivit.

Ilmainen Supabase-tietoturvatarkistus ei lue frontendiäsi, mutta se lukee saman ongelman tietokantapuolen: RLS:n ohittavat roolit, taulut ilman RLS:ää, politiikat, jotka päästävät läpi jokaisen rivin, ja sarakkeet, jotka näyttävät arkaluonteisilta ja ovat anonyymien kävijöiden luettavissa. Miten tarkistat, mihin julkinen avaimesi käytännössä yltää, kerron artikkelissa vibe coding security risks, ja koko listan, jonka ajan sovelluksella, löydät Lovable-sovelluksen tietoturvatarkistuslistastani.