Supabase anon key vs service role key: čo ktorý otvorí

Som Denys, full-stack a AI inžinier. Uniknutý secret key je prvá vec, ktorú hľadám, keď prevezmem aplikáciu na Supabase, pretože s ním je každá ďalšia ochrana len dekorácia. Tento článok vysvetľuje, čo ktorý kľúč otvára, s požiadavkami, ktoré som spustil, aby som to overil.

Čo je Supabase anon key?

Anon key identifikuje vašu aplikáciu, nie vášho používateľa. Nesie ho každá požiadavka z prehliadača alebo mobilnej aplikácie, takže musí byť verejný: ktokoľvek si ho prečíta v zdroji stránky. Požiadavka len s týmto kľúčom beží ako rola Postgresu anon. Keď sa používateľ prihlási cez Supabase Auth, rovnaký kľúč cestuje s tokenom používateľa a požiadavka beží ako authenticated. Vaše politiky RLS sú písané pre tieto dve roly.

Supabase kľúče premenúva. Sprievodca API kľúčmi nazýva nové publishable (sb_publishable_…) a secret (sb_secret_…) a staršie kľúče anon a service_role založené na JWT označuje za zastarané do konca roka 2026. Roly za nimi zostávajú rovnaké.

Kľúč	Starší názov	Rola v Postgrese	Platí RLS?	Kam patrí
Publishable sb_publishable_…	kľúč anon	anon, alebo authenticated s tokenom používateľa	Áno	Prehliadač, mobilná aplikácia, čokoľvek, čo doručujete
Secret sb_secret_…	kľúč service_role	service_role	Nie, rola má BYPASSRLS	Len server, Edge Function, cron úloha

Je bezpečné odhaliť Supabase anon key?

Áno, ak je chránená každá tabuľka, view a funkcia, kam dosiahne. Samotný kľúč nedáva nič zvláštne; o všetkom rozhodujú granty a politiky vo vašej schéme. Overil som to na lokálnom Supabase (CLI 2.109.1, Postgres 17.6) s jednou tabuľkou o troch fiktívnych objednávkach:

Stav tabuľky	Publishable key	Secret key
RLS vypnuté	Všetky 3 riadky a vloženie vrátilo 201 Created	Všetky 3 riadky
RLS zapnuté, bez politiky	[]	Všetky 3 riadky
RLS zapnuté, politika using (true)	Všetky 3 riadky	Všetky 3 riadky
Bez grantu pre anon	42501 permission denied s nápovedou menujúcou chýbajúci GRANT	Všetky 3 riadky

Publishable key je teda rovnako bezpečný ako vaša najslabšia tabuľka. Tabuľku bez RLS alebo s politikou, ktorá povoľuje každý riadok, prečíta každý, kto otvorí DevTools. To je diera za CVE-2025-48757, kde 170 z 1 645 ukážkových aplikácií z Lovable vydávalo dáta verejnému kľúču.

Čo je service role key a prečo je nebezpečný?

Secret key je hlavný kľúč. Beží ako service_role, ktorá má atribút BYPASSRLS, takže sa naň žiadna vaša politika nikdy nevzťahuje. V poslednom stĺpci tabuľky vyššie prečítal všetky tri riadky v každom stave. Sprievodca Supabase uvádza, kam patrí: servery, ktoré vykonávajú vlastné kontroly autorizácie, Edge Functions, úlohy na pozadí a administrátorské nástroje. Dva detaily zo sprievodcu záležia v praxi:

• Nový secret key odmieta požiadavky z prehliadača: Supabase porovná User-Agent a vráti 401. Starší JWT service_role takú kontrolu nemá, takže uniknutý starší kľúč funguje odkiaľkoľvek. Môj lokálny stack, ktorý takú kontrolu na bráne nemá, odpovedal skriptu so secret key všetkými 3 riadkami.
• Secret key obchádza RLS len vtedy, keď požiadavka nenesie token používateľa. S tokenom prihláseného používateľa požiadavka beží pod politikami toho používateľa.

Edge Function, ktorá používa secret key, musí sama skontrolovať, kto volá, a filtrovať podľa vlastníka alebo firmy, pretože pod ňou to neurobí nič.

Kde kľúče nájdete?

V Dashboarde otvorte dialóg Connect svojho projektu pre URL a publishable key, alebo Settings → API Keys pre všetky kľúče vrátane starších. Lokálne supabase start a supabase status vypíšu publishable key a secret key. Držte ich v premenných prostredia: v Next.js smie predponu NEXT_PUBLIC_ niesť len publishable key, pretože bundler doručí do prehliadača čokoľvek s touto predponou.

Čo robiť, keď service role key unikol?

Berte ho ako kompromitovaný: každý riadok v každej tabuľke mohol čítať aj zapisovať ten, kto ho našiel.

1. Vytvorte nový secret key, prepnite naň svoje servery a uniknutý zmažte. Ak unikol starší kľúč service_role, cesta von je prechod na nové kľúče: vytvorte publishable a secret key, prepnite aplikáciu a potom staršie kľúče vypnite v Settings → API Keys, kde inak zostávajú platné.
2. Prehľadajte zostavený JavaScript a históriu Gitu na sb_secret_ a service_role. Sken 5 600 aplikácií z vibe codingu od Escape našiel viac než 400 odhalených tajomstiev, väčšinu vo frontendových bundloch.
3. Skontrolujte, čo sa zmenilo, kým bol vonku: noví používatelia, zmeny rolí, zmazané riadky.

Bezplatná Kontrola zabezpečenia Supabase váš frontend nečíta, ale číta stranu databázy toho istého problému: roly, ktoré obchádzajú RLS, tabuľky s vypnutým RLS, politiky, ktoré povoľujú každý riadok, a stĺpce, ktoré vyzerajú citlivo a anonymní návštevníci ich môžu čítať. Ako overiť, kam váš verejný kľúč v praxi dosiahne, je v článku bezpečnostné riziká vibe codingu a celý zoznam, ktorý na aplikácii spúšťam, je v mojom checkliste bezpečnosti aplikácie z Lovable.