--- title: "Supabase anon key vs service role key: ko katra atver" description: "Supabase anon (publishable) key pārlūkā ir droša tikai aiz RLS, service role (secret) key RLS apiet. Kur katra pieder, pārbaudīts lokālā vidē." url: "https://madsalt.tech/lv/blog/supabase-anon-key-vs-service-role-key/" author: "Denys Zaichenko" language: "lv" published: 2026-10-25 --- # Supabase anon key vs service role key: ko katra atver Īsumā Anon key, ko tagad sauc par publishable key, ir paredzēta publiskai lietošanai: tā atbilst lomai `anon` vai `authenticated`, un jūsu RLS politikas nosaka, ko tā redz. Service role key, tagad secret key, atbilst lomai `service_role`, kas pilnībā apiet RLS. Manā lokālajā testa tabulā ar ieslēgtu RLS un bez politikas publiskā atslēga ieguva 0 rindu, bet secret key visas 3. Ievietojiet publishable key pārlūkā, turiet secret key serverī un nomainiet to, ja tā kādreiz tika piegādāta lietotājiem. Esmu Denys, full-stack un AI inženieris. Noplūdusi secret key ir pirmais, ko meklēju, pārņemot Supabase lietotni, jo ar to visa pārējā aizsardzība ir tikai dekors. Šajā rakstā paskaidrots, ko katra atslēga atver, ar pieprasījumiem, ko palaidu, lai to pārbaudītu. ## Kas ir Supabase anon key? Anon key identificē jūsu lietotni, nevis jūsu lietotāju. To nes katrs pieprasījums no pārlūka vai mobilās lietotnes, tāpēc tai jābūt publiskai: ikviens var to izlasīt lapas pirmkodā. Pieprasījums tikai ar šo atslēgu darbojas kā Postgres loma `anon`. Kad lietotājs piesakās caur Supabase Auth, tā pati atslēga ceļo kopā ar lietotāja tokenu, un pieprasījums darbojas kā `authenticated`. Jūsu RLS politikas ir rakstītas šīm divām lomām. Supabase atslēgas pārdēvē. [API keys ceļvedis](https://supabase.com/docs/guides/api/api-keys) jaunās sauc par publishable (`sb_publishable_…`) un secret (`sb_secret_…`), bet vecās JWT balstītās `anon` un `service_role` atslēgas atzīst par novecojušām līdz 2026. gada beigām. Lomas to aizmugurē paliek tās pašas. | Atslēga | Vecais nosaukums | Postgres loma | Vai RLS darbojas? | Kur tā ir | | ------------------------------ | ------------------ | ----------------------------------------------- | ------------------------ | --------------------------------------------------------- | | Publishable `sb_publishable_…` | `anon` key | `anon`, vai `authenticated` ar lietotāja tokenu | Jā | Pārlūks, mobilā lietotne, viss, ko piegādājat lietotājiem | | Secret `sb_secret_…` | `service_role` key | `service_role` | Nē, lomai ir `BYPASSRLS` | Tikai serveris, Edge Function, cron darbs | ## Vai ir droši atklāt Supabase anon key? Jā, ja ir aizsargāta katra tabula, skats un funkcija, ko tā var sasniegt. Pati atslēga nedod neko īpašu; visu nosaka tiesības (grants) un politikas jūsu shēmā. To pārbaudīju lokālā Supabase vidē (CLI 2.109.1, Postgres 17.6) ar vienu tabulu ar trim izdomātiem pasūtījumiem: ![Kādā Postgres lomā pārvēršas katra atslēga. Un vai jūsu RLS politikas redz pieprasījumu. Publishable key, bez pieteikšanās: Publishable key → loma anon → RLS politikas darbojas; Publishable key, pēc pieteikšanās: Publishable key + lietotāja tokens → loma authenticated → RLS politikas darbojas; Secret key: Secret key → loma service_role → RLS izlaists.](https://madsalt.tech/charts/lv/supabase-anon-key-vs-service-role-key.svg) *1. attēls. No Supabase API keys ceļveža, pārbaudīts lokālā vidē, 2026. gada 23. oktobris.* | Tabulas stāvoklis | Publishable key | Secret key | | ------------------------------------- | ----------------------------------------------------------------- | -------------- | | RLS izslēgts | Visas 3 rindas, un ievietošana atgrieza `201 Created` | Visas 3 rindas | | RLS ieslēgts, politikas nav | `[]` | Visas 3 rindas | | RLS ieslēgts, politika `using (true)` | Visas 3 rindas | Visas 3 rindas | | Lomai `anon` nav tiesību | `42501 permission denied` ar norādi, kas nosauc trūkstošo `GRANT` | Visas 3 rindas | Tātad publishable key ir tik droša, cik jūsu vājākā tabula. Tabula bez RLS vai ar politiku, kas atļauj katru rindu, ir lasāma ikvienam, kas atver DevTools. Tas ir robs, kas stāv aiz [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), kur 170 no 1645 Lovable demonstrācijas lietotnēm atdeva datus publiskajai atslēgai. ## Kas ir service role key un kāpēc tā ir bīstama? Secret key ir galvenā atslēga. Tā darbojas kā `service_role`, kam ir atribūts `BYPASSRLS`, tāpēc neviena jūsu uzrakstīta politika tai nekad nepiemērojas. Augstāk esošās tabulas pēdējā kolonnā tā nolasīja visas trīs rindas katrā stāvoklī. Supabase ceļvedis uzskaita, kur tā pieder: serveri, kas paši veic autorizācijas pārbaudes, Edge Function, fona darbi un administrēšanas rīki. Divas ceļveža detaļas praksē ir svarīgas: - Jaunā secret key atsaka pārlūka pieprasījumus: Supabase salīdzina `User-Agent` un atgriež `401`. Vecajai `service_role` JWT šādas pārbaudes nav, tāpēc noplūdusi veca atslēga darbojas no jebkuras vietas. Mana lokālā vide, kurā šādas vārtejas pārbaudes nav, uz skriptu ar secret key atbildēja ar visām 3 rindām. - Secret key apiet RLS tikai tad, ja pieprasījums nenes lietotāja tokenu. Ar pieteikušā lietotāja tokenu pieprasījums darbojas pēc šī lietotāja politikām. Edge Function, kas izmanto secret key, pašai jāpārbauda, kas zvana, un jāfiltrē pēc īpašnieka vai uzņēmuma, jo zem tās to nedara nekas. ## Kur atrast atslēgas? Dashboard atveriet projekta Connect dialogu URL un publishable key iegūšanai vai Settings → API Keys visām atslēgām, ieskaitot vecās. Lokāli `supabase start` un `supabase status` izdrukā publishable key un secret key. Glabājiet tās vides mainīgajos: Next.js prefiksu `NEXT_PUBLIC_` drīkst nest tikai publishable key, jo bundler nosūta pārlūkam visu ar šo prefiksu. ## Ko darīt, ja service role key noplūda? Uzskatiet to par kompromitētu: katra rinda katrā tabulā bija lasāma un rakstāma ikvienam, kas to atrada. 1. Izveidojiet jaunu secret key, pārvietojiet serverus uz to, tad dzēsiet noplūdušo. Ja noplūda veca `service_role` key, izeja ir pāreja uz jaunajām atslēgām: izveidojiet publishable un secret key, pārslēdziet lietotni, tad atspējojiet vecās atslēgas sadaļā Settings → API Keys, kur citādi tās paliek spēkā. 2. Meklējiet uzbūvētajā JavaScript un Git vēsturē `sb_secret_` un `service_role`. Escape 5600 vibe coding lietotņu skenēšana atrada [vairāk nekā 400 atklātu noslēpumu](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), lielākā daļa frontend bundle. 3. Pārskatiet, kas mainījās, kamēr atslēga bija ārā: jauni lietotāji, lomu izmaiņas, izdzēstas rindas. Bezmaksas [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/) nelasa jūsu frontend, bet nolasa tās pašas problēmas datubāzes pusi: lomas, kas apiet RLS, tabulas ar izslēgtu RLS, politikas, kas atļauj katru rindu, un kolonnas, kas izskatās sensitīvas un ir lasāmas anonīmiem apmeklētājiem. Lai pārbaudītu, ko jūsu publiskā atslēga praksē sasniedz, soļi ir rakstā [vibe coding drošības riski](https://madsalt.tech/lv/blog/vibe-coding-security-risks/), bet pilnais saraksts, ko palaižu lietotnei, ir manā [Lovable lietotnes drošības kontrolsarakstā](https://madsalt.tech/lv/blog/lovable-app-security-checklist/). Neesat pārliecināti, kuru atslēgu piegādā jūsu lietotne? Labprāt paskatīšos un salīdzināšu pieredzi. Bez pārdošanas sarunas. [Sazināties](https://madsalt.tech/lv/#contact)