Clau de rol de servei de Supabase exposada a JavaScript: què significa i com detectar-la

Què és la clau de rol de servei

Supabase emet dues claus diferents per a cada projecte: la clau anon (també anomenada clau publicable en projectes més nous) i la clau service_role. Totes dues són JSON Web Tokens signats amb el secret JWT del teu projecte. La diferència és el claim role incorporat al payload del JWT — anon per a la clau pública, service_role per a la clau mestra. PostgREST, Supabase Storage i Supabase Auth passen a un mode de saltar-s'ho-tot quan veuen el claim service_role.

Descodifica qualsevol clau de Supabase a jwt.io i mira el payload. La forma d'un JWT de rol de servei és inconfusible:

Payload descodificat d'un JWT de rol de servei (mostrat com a bloc ressaltat a sota).

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

Els projectes Supabase més nous emeten claus de tipus secret amb el prefix sb_secret_ en lloc d'un JWT. El comportament és idèntic — qualsevol cosa que contingui sb_secret_ en un bundle públic és igual de catastròfica.

Com les eines de codificació amb IA filtren la clau de rol de servei

Hem vist els mateixos tres patrons en milers d'aplicacions generades amb IA. Cadascun comença amb un desenvolupador demanant ajuda a una eina d'IA i acaba amb la clau de servei incrustada en un bundle.

Patró 1: fitxer .env únic amb prefix NEXT_PUBLIC_

El desenvolupador demana a l'eina d'IA que "configuri Supabase" i accepta un sol .env amb totes dues claus. L'eina d'IA — entrenada amb un corpus on la majoria de variables d'entorn s'exposen via NEXT_PUBLIC_* — prefixa totes dues amb NEXT_PUBLIC_. Next.js incrusta qualsevol cosa que coincideixi amb aquest prefix al bundle client en temps de compilació. Publiques a Vercel i la clau de servei queda dins main.[hash].js.

Patró 2: clau incorrecta a la crida createClient

El desenvolupador enganxa totes dues claus en un fitxer config.ts generat per la IA, i la IA omple per error la crida createClient() del costat del navegador amb process.env.SUPABASE_SERVICE_ROLE_KEY. La compilació porta la variable i el JWT acaba al bundle.

Patró 3: clau de rol de servei incrustada en scripts de seed

El desenvolupador demana a l'eina d'IA que escrigui un script per poblar la base de dades. La IA incrusta la clau de rol de servei directament al fitxer (en lloc de llegir-la de l'entorn), confirma el fitxer al repositori, i el repositori públic de GitHub o la ruta /scripts/seed.js de l'aplicació desplegada ara està servint la clau.

Com detecta la fuita l'escaneig de bundle de FixVibe

La comprovació de secrets en bundle de FixVibe descarrega cada fitxer JavaScript referenciat per l'aplicació desplegada — chunks d'entrada, chunks de càrrega diferida, web workers, service workers — i els passa per un detector que descodifica qualsevol cosa que coincideixi amb la forma de JWT (eyJ[base64-header].eyJ[base64-payload].[signature]). Si el payload descodificat conté "role": "service_role", l'escaneig ho reporta com a troballa crítica amb la ruta del fitxer i la línia exacta on apareix la clau. La mateixa comprovació també detecta el patró més nou sb_secret_* per prefix.

L'escaneig mai s'autentica amb la clau descoberta. Identifica la forma i informa de la fuita — fer servir la clau per demostrar l'explotabilitat seria un accés no autoritzat a la teva base de dades. La prova és al mateix payload del JWT.

Detectada — què fer en la primera hora

Una clau de rol de servei filtrada és una emergència en temps d'execució. Assumeix que la clau ha estat extreta — els atacants monitoritzen bundles públics en temps real. Tracta la base de dades com a compromesa fins que hagis rotat la clau i auditat l'activitat recent.

1. Rota la clau immediatament. Al panell de Supabase, ves a Project Settings → API → Service role key → Reset. La clau antiga queda invalidada en segons. Qualsevol codi del costat del servidor que faci servir la clau s'ha d'actualitzar i redesplegar abans que la rotació es faci efectiva.
2. Audita l'activitat recent de la base de dades. Obre Database → Logs al panell. Filtra pels darrers 7 dies. Cerca consultes SELECT * inusuals contra taules amb PII, instruccions UPDATE o DELETE grans i sol·licituds des d'IPs fora de la teva infraestructura coneguda. Supabase registra la capçalera x-real-ip a cada sol·licitud.
3. Comprova els objectes d'emmagatzematge. Visita Storage → Logs i revisa les descàrregues de fitxers recents. Una clau de rol de servei filtrada també atorga accés de saltar-s'ho-tot als contenidors privats.
4. Elimina la clau del control de versions. Fins i tot després de la rotació, deixar el JWT al teu historial de git significa que es pot descobrir al repositori públic. Fes servir git filter-repo o BFG Repo-Cleaner per netejar-lo de l'historial, i després fes force-push (avisa abans els col·laboradors).
5. Torna a escanejar després de la correcció. Executa un nou escaneig de FixVibe contra l'aplicació redesplegada. La troballa de secrets en bundle hauria de desaparèixer. Confirma que no queda cap JWT service_role ni cap cadena sb_secret_* en cap chunk.

Prevenir la fuita des de l'inici

La correcció estructural és disciplina de nomenclatura més mesures de seguretat a nivell d'eines:

• No prefixis mai la clau de servei amb NEXT_PUBLIC_*, VITE_* ni cap altre prefix que incrusti al bundle. La convenció de nomenclatura és el límit — tots els frameworks la respecten.
• Mantén la clau de servei completament fora del .env de la màquina del desenvolupador. Llegeix-la d'un gestor de secrets (Doppler, Infisical, variables d'entorn xifrades de Vercel) al desplegament, mai la confirmis localment.
• <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.
• Afegeix una porta de CI que escanegi la sortida de la compilació. Després de next build, fes grep a la sortida de .next/static/chunks/ per la cadena service_role. Falla la compilació si hi ha alguna coincidència.

# 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

Preguntes freqüents

Següents passos

Executa un escaneig de FixVibe contra el teu URL de producció — la comprovació de secrets en bundle és gratuïta, sense registre, i informa de l'exposició de service_role en menys d'un minut. Combina-ho amb l'article Escàner de RLS de Supabase per verificar que la capa RLS fa la seva feina, i la Llista de comprovació de seguretat de contenidors de Supabase Storage per blindar l'accés als fitxers. Per saber per què les eines d'IA generen aquesta classe de fuita de manera tan fiable, llegeix Per què les eines de codificació amb IA deixen mancances de seguretat.