--- title: "Supabase anon key vs service role key: čo ktorý otvorí" description: "Supabase anon key (publishable key) je v prehliadači bezpečný len za RLS; service role key (secret key) RLS obchádza. Kam ktorý patrí, overené lokálne." url: "https://madsalt.tech/sk/blog/supabase-anon-key-vs-service-role-key/" author: "Denys Zaichenko" language: "sk" published: 2026-10-25 --- # Supabase anon key vs service role key: čo ktorý otvorí TL;DR Anon key, dnes nazývaný publishable key, je určený na to, aby bol verejný: mapuje sa na rolu `anon` alebo `authenticated` a o tom, čo uvidí, rozhodujú vaše politiky RLS. Service role key, dnes secret key, sa mapuje na `service_role`, ktorá RLS obchádza úplne. Na mojej lokálnej testovacej tabuľke so zapnutým RLS a bez politiky dostal publishable key 0 riadkov a secret key všetky 3. Publishable key patrí do prehliadača, secret key na server, a ak niekedy unikol, vymeňte ho. 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](https://supabase.com/docs/guides/api/api-keys) 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: ![Akou rolou v Postgrese sa každý kľúč stane. A či vašu požiadavku vidia politiky RLS. Publishable key, odhlásený: Publishable key → rola anon → Politiky RLS platia; Publishable key, prihlásený: Publishable key + token používateľa → rola authenticated → Politiky RLS platia; Secret key: Secret key → rola service_role → RLS preskočené.](https://madsalt.tech/charts/sk/supabase-anon-key-vs-service-role-key.svg) *Obrázok 1. Zo sprievodcu API kľúčmi Supabase, overené na lokálnom stacku, 23. októbra 2026.* | 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](https://mattpalmer.io/posts/2025/05/statement-on-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](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), 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](https://madsalt.tech/sk/tools/supabase-security-check/) 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](https://madsalt.tech/sk/blog/vibe-coding-security-risks/) a celý zoznam, ktorý na aplikácii spúšťam, je v mojom [checkliste bezpečnosti aplikácie z Lovable](https://madsalt.tech/sk/blog/lovable-app-security-checklist/). Nie ste si istí, ktorý kľúč vaša aplikácia doručuje? Rád sa pozriem a porovnám skúsenosti. Bez ponuky. [Ozvite sa](https://madsalt.tech/sk/#contact)