Supabase anon key vs service role key: ko katra atver

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

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, 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, 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 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, bet pilnais saraksts, ko palaižu lietotnei, ir manā Lovable lietotnes drošības kontrolsarakstā.