// docs / baas security / supabase service role exposure

Supabase service-role-lykill opinberaður í JavaScript: hvað það þýðir og hvernig á að finna hann

Q: Getur RLS verndað mig ef service-role-lykillinn lekur?

Nei. Row-Level Security er algjörlega sniðgengin af service_role-fullyrðingunni. Það er með hönnun — lykillinn er til einmitt til þess að leyfa bakgrunnskóða að sleppa RLS fyrir admin-aðgerðir. Mótvægið er að tryggja að lykillinn nái aldrei samhengi þar sem árásarmaður getur lesið hann.

Q: Á þetta við um nýja Supabase útgefanlega / leyndar-lykla-líkanið ( sb_publishable_ / sb_secret_ )?

Já — eins áhættuflokkur. sb_secret_*-lykillinn er nýja leyndarlyklasniðið sem kemur í stað service-role-JWT fyrir nýrri verkefni. Allt sem ber sb_secret_* í knippi er jafn skaðlegt og lekur service-role-JWT. FixVibe bundle-secrets-greinirinn passar bæði sniðin.

Supabase service-role-lykillinn er aðallykillinn að gagnagrunninum þínum. Sá sem hefur hann sniðgengur Row-Level Security, getur lesið hvern dálk í hverri töflu og getur skrifað eða eytt hverju sem þeir velja. Hann er hannaður til að búa eingöngu í kóða á netþjónshlið — aldrei í vafranum. Þegar AI-kóðunarverkfæri sendir hann í JavaScript-knippið er gagnagrunnurinn þinn í raun opinber. Þessi grein útskýrir JWT-sniðið sem auðkennir lekan lykil, þrjú AI-verkfæramynstur sem framleiða lekann, hvað á að gera fyrstu klukkustundina eftir uppgötvun, og hvernig á að skanna eftir honum sjálfvirkt áður en notendur gera það.

Hvað service-role-lykillinn er

Supabase gefur út tvo aðskilda lykla fyrir hvert verkefni: anon-lykilinn (einnig kallaður útgefanlegi lykillinn í nýrri verkefnum) og service_role-lykilinn. Báðir eru JSON Web Tokens undirritaðir af JWT-leynd verkefnisins. Munurinn er role-fullyrðingin sem er bökuð inn í JWT-greiðsluna — anon fyrir opinbera lykilinn, service_role fyrir aðallykilinn. PostgREST, Supabase Storage og Supabase Auth fara öll í bypass-allt-stillingu þegar þau sjá service_role-fullyrðinguna.

Afkóðaðu hvaða Supabase-lykil sem er á jwt.io og skoðaðu greiðsluna. Snið service-role-JWT er ótvírætt:

Afkóðuð greiðsla service-role-JWT (sýnd sem setningarfræðilýst blokk hér að neðan).

json

{
  "iss": "supabase",
  "ref": "[project-ref]",
  "role": "service_role",
  "iat": 1700000000,
  "exp": 2000000000
}

Nýrri Supabase-verkefni gefa út leyndarlykla með forskeytinu sb_secret_ í stað JWT. Hegðunin er eins — allt sem ber sb_secret_ í opinberu knippi er jafn skaðlegt.

Hvernig AI-kóðunarverkfæri leka service-role-lyklinum

Við höfum séð sömu þrjú mynstrin í þúsundum vibe-kóðaðra forrita. Hvert byrjar á því að þróunaraðili biður AI-verkfæri um aðstoð og endar með að service-lykillinn er innlímdur í knippi.

Mynstur 1: Ein .env-skrá með NEXT_PUBLIC_-forskeyti

Þróunaraðilinn biður AI-verkfærið um að "setja upp Supabase" og samþykkir eina .env með báðum lyklum. AI-verkfærið — þjálfað á gagnagrunni þar sem flestar umhverfisbreytur eru opnaðar í gegnum NEXT_PUBLIC_* — setur NEXT_PUBLIC_ fyrir framan báða. Next.js innlímir allt sem passar við það forskeyti inn í biðlaraknippið við smíði. Sendu á Vercel, og service-lykillinn er í main.[hash].js.

Mynstur 2: Rangur lykill í createClient-kalli

Þróunaraðilinn límir báða lykla inn í config.ts-skrá sem AI-ið bjó til, og AI-ið fyllir út biðlaramegin createClient()-kall með process.env.SUPABASE_SERVICE_ROLE_KEY fyrir mistök. Smíðin tekur breytuna inn, og JWT-ið lendir í knippinu.

Mynstur 3: Service-role-lykill harðkóðaður í fræskriftum

Þróunaraðilinn biður AI-verkfærið um að skrifa skriftu sem fræir gagnagrunninn. AI-ið harðkóðar service-role-lykilinn beint í skrána (frekar en að lesa úr umhverfi), staðfestir skrána í endurhverfunni, og opinbera GitHub-endurhverfan eða /scripts/seed.js-slóð uppsetta forritsins framreiðir nú lykilinn.

Hvernig FixVibe-knippisskönnunin finnur lekann

FixVibe bundle-secrets-athugunin sækir hverja JavaScript-skrá sem uppsetta forritið vísar í — inngangsbúta, lazy-hlaðna búta, vefnema, þjónustunema — og keyrir þá í gegnum greiniri sem afkóðar allt sem passar við JWT-snið (eyJ[base64-header].eyJ[base64-payload].[signature]). Ef afkóðaða greiðslan inniheldur "role": "service_role", tilkynnir skönnunin það sem alvarlega niðurstöðu með skrárslóðinni og nákvæmu línunni þar sem lykillinn birtist. Sama athugun passar einnig nýrra sb_secret_*-mynstrið eftir forskeyti.

Skönnunin auðkennir sig aldrei með uppgötvaða lyklinum. Hún auðkennir sniðið og tilkynnir lekann — að nota lykilinn til að sanna nýtanleika væri óheimill aðgangur að gagnagrunninum þínum. Sönnunin er í sjálfri JWT-greiðslunni.

Greindur — hvað á að gera fyrstu klukkustundina

Lekur service-role-lykill er keyrsluneyðarástand. Gerðu ráð fyrir að lykillinn hafi verið skrapaður — árásarmenn vakta opinber knippi í rauntíma. Meðhöndlaðu gagnagrunninn sem ógnaðan þar til þú hefur snúið lyklinum og endurskoðað nýlega virkni.

Snúðu lyklinum strax. Í Supabase Dashboard, farðu í Project Settings → API → Service role key → Reset. Gamli lykillinn er ógiltur innan sekúndna. Sérhver netþjónamegin kóði sem notar lykilinn verður að uppfæra og endurútgefa áður en snúningurinn lendir.
Endurskoðaðu nýlega gagnagrunnsvirkni. Opnaðu Database → Logs í mælaborðinu. Síaðu á síðustu 7 daga. Leitaðu að óvenjulegum SELECT *-fyrirspurnum gegn töflum með PII, stórum UPDATE- eða DELETE-yfirlýsingum, og beiðnum frá IP-tölum utan þekktrar innviða þinna. Supabase skráir x-real-ip-hausinn á hverri beiðni.
Athugaðu geymsluhluti. Heimsæktu Storage → Logs og skoðaðu nýlegar fílaniðurhalanir. Lekur service-role-lykill veitir bypass-allt-aðgang einnig að einkafötum.
Fjarlægðu lykilinn úr frumkóðastýringu. Jafnvel eftir snúning þýðir það að skilja JWT eftir í git-sögunni þinni að það er hægt að finna það í opinberu endurhverfunni. Notaðu git filter-repo eða BFG Repo-Cleaner til að hreinsa það úr sögunni, og þvinguðu síðan ýtinguna (varaðu samstarfsmenn fyrst).
Skannaðu aftur eftir lagfæringu. Keyrðu nýja FixVibe-skönnun gegn endurútgefnu forritinu. Bundle-secrets-niðurstaðan ætti að hverfa. Staðfestu að engin service_role-JWT og enginn sb_secret_*-strengur sé eftir í neinum búti.

Að koma í veg fyrir lekann í fyrsta lagi

Skipulagslega lagfæringin er nafnaagi auk verkfæralágra varúða:

Settu aldrei service-lykilinn með NEXT_PUBLIC_*, VITE_* eða öðru knippa-innlímandi forskeyti. Nafnasáttmálinn er mörkin — sérhver rammi virðir hann.
Haltu service-lyklinum algjörlega utan .env á þróunarvélinni. Lestu hann frá leyndarmálastjórnanda (Doppler, Infisical, Vercel dulkóðaðar env-breytur) við útgáfu, staðfestu hann aldrei staðbundið.
<strong>Mark every Supabase client construction with explicit context.</strong> Files named <code>supabase/browser.ts</code> use the anon key; files named <code>supabase/server.ts</code> use the service-role key with <code>import 'server-only'</code> at the top. The <code>server-only</code> import causes a build error if a client component tries to consume the module.
<strong>Add a pre-commit hook that greps for JWT-shaped strings.</strong> <code>git diff --staged | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+'</code> catches both anon and service tokens before they leave your machine.
Bættu við CI-hliði sem skannar smíðisúttakið. Eftir next build, greppaðu .next/static/chunks/-úttakið fyrir strenginn service_role. Láttu smíðina bregðast ef eitthvað passar.

bash

# Pre-commit hook: refuse any staged JWT-shaped string.
git diff --staged \
  | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+' \
  && echo "JWT detected in staged changes — refusing commit" \
  && exit 1

# CI gate: fail the build if "service_role" shipped to the static bundle.
grep -RE 'service_role|sb_secret_' .next/static/chunks/ \
  && echo "Service-role credential leaked into bundle" \
  && exit 1

Algengar spurningar

Hversu hratt finna árásarmenn í raun lekna Supabase service-role-lykla?

Skannar opinberra knippa toga ný uppsetning á mínútum. Rannsakendur hafa skjalfest virka nýtingu gegn nýjum Supabase-verkefnum á innan við einni klukkustund frá fyrstu útgáfu. Meðhöndlaðu hverja service-role-opinberun sem 60-mínútna glugga, ekki 60-daga.

Er nóg að snúa lyklinum, eða þarf ég að gera ráð fyrir gagnaútdrætti?

Snúningur ógildir lekna lykilinn en afturkallar ekki gögn sem þegar voru sótt. Ef töflurnar þínar innihalda PII, greiðslugögn eða önnur eftirlitsskyld gögn, gætir þú haft tilkynningarskyldu samkvæmt GDPR (72 klukkustundir), CCPA eða HIPAA. Endurskoðaðu skrárnar og leitaðu lögfræðiráðgjafar ef endurskoðunin sýnir grunsamlegan aðgang.

Getur RLS verndað mig ef service-role-lykillinn lekur?

Nei. Row-Level Security er algjörlega sniðgengin af service_role-fullyrðingunni. Það er með hönnun — lykillinn er til einmitt til þess að leyfa bakgrunnskóða að sleppa RLS fyrir admin-aðgerðir. Mótvægið er að tryggja að lykillinn nái aldrei samhengi þar sem árásarmaður getur lesið hann.

Á þetta við um nýja Supabase útgefanlega / leyndar-lykla-líkanið (<code>sb_publishable_</code> / <code>sb_secret_</code>)?

Já — eins áhættuflokkur. sb_secret_*-lykillinn er nýja leyndarlyklasniðið sem kemur í stað service-role-JWT fyrir nýrri verkefni. Allt sem ber sb_secret_* í knippi er jafn skaðlegt og lekur service-role-JWT. FixVibe bundle-secrets-greinirinn passar bæði sniðin.

Hvað með anon-/útgefanlega lykilinn — er hann öruggur í knippinu?

Já, með hönnun. Anon-lykillinn er ætlaður til að búa í vafranum og er það sem hver Supabase-vefbiðlari notar. Öryggi hans er algjörlega háð því að RLS sé rétt stillt á hverri opinberri töflu. Sjáðu Supabase RLS-skanni-greinina fyrir það sem þarf að athuga.

Næstu skref

Keyrðu FixVibe-skönnun gegn framleiðslu-URL þínum — bundle-secrets-athugunin er ókeypis, engin skráning, og tilkynnir service_role-opinberun á innan við einni mínútu. Paraðu þetta við Supabase RLS-skanni-greinina til að staðfesta að RLS-lagið vinni sitt verk, og Supabase geymslufötu öryggisgátlisti til að læsa fílaaðgang. Fyrir bakgrunn um hvers vegna AI-verkfæri framleiða þennan lekaflokk svo áreiðanlega, lestu Hvers vegna AI-kóðunarverkfæri skilja eftir öryggisgöt.