Clave de rol de servizo de Supabase exposta en JavaScript: que significa e como atopala

Que é a clave de rol de servizo

Supabase emite dúas claves distintas para cada proxecto: a clave anon (tamén chamada clave publicábel nos proxectos máis novos) e a clave service_role. Ambas son JSON Web Tokens asinados polo segredo JWT do teu proxecto. A diferenza é o claim role incrustado na carga útil do JWT — anon para a clave pública, service_role para a clave mestra. PostgREST, Supabase Storage e Supabase Auth todos pasan ao modo saltar-todo cando ven o claim service_role.

Descodifica calquera clave de Supabase en jwt.io e mira a carga útil. A forma dun JWT de rol de servizo é inconfundible:

Carga útil descodificada dun JWT de rol de servizo (móstrase nun bloque resaltado por sintaxe a continuación).

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

Os proxectos Supabase máis novos emiten claves de estilo secreto co prefixo sb_secret_ en vez dun JWT. O comportamento é idéntico — calquera cousa que leve sb_secret_ nun bundle público é igualmente catastrófica.

Como as ferramentas de codificación con IA filtran a clave de rol de servizo

Vimos os mesmos tres patróns en miles de aplicacións xeradas por IA. Cada un comeza cun desenvolvedor pedíndolle axuda a unha ferramenta de IA e remata coa clave de servizo embebida nun bundle.

Patrón 1: Un único ficheiro .env con prefixo NEXT_PUBLIC_

O desenvolvedor pídelle á ferramenta de IA que "configure Supabase" e acepta un único .env con ambas as claves. A ferramenta de IA — adestrada nun corpus onde a maioría das variables de contorno expóñense vía NEXT_PUBLIC_* — prefixa as dúas con NEXT_PUBLIC_. Next.js incrusta calquera cousa que coincida con ese prefixo no bundle do cliente no momento de compilación. Publica en Vercel, e a clave de servizo está en main.[hash].js.

Patrón 2: Clave incorrecta na chamada createClient

O desenvolvedor pega ambas as claves nun ficheiro config.ts que xerou a IA, e a IA enche a chamada createClient() do lado do navegador con process.env.SUPABASE_SERVICE_ROLE_KEY por erro. A compilación importa a variable e o JWT aterra no bundle.

Patrón 3: Clave de rol de servizo codificada en scripts de sementado

O desenvolvedor pídelle á ferramenta de IA que escriba un script que sementa a base de datos. A IA codifica directamente a clave de rol de servizo no ficheiro (no canto de lela do contorno), confirma o ficheiro no repositorio e o repositorio público de GitHub ou a ruta /scripts/seed.js da aplicación despregada serven agora a clave.

Como o escaneo de bundle de FixVibe detecta a fuga

A comprobación de segredos no bundle de FixVibe descarga cada ficheiro JavaScript referenciado pola aplicación despregada — chunks de entrada, chunks cargados de forma diferida, web workers, service workers — e fainos pasar por un detector que descodifica calquera cousa que coincida coa forma de JWT (eyJ[base64-header].eyJ[base64-payload].[signature]). Se a carga útil descodificada contén "role": "service_role", o escaneo infórmao como un achado crítico co camiño do ficheiro e a liña exacta onde aparece a clave. A mesma comprobación tamén coincide co novo patrón sb_secret_* por prefixo.

O escaneo nunca se autentica coa clave descuberta. Identifica a forma e informa da fuga — utilizar a clave para probar a explotabilidade sería acceso non autorizado á túa base de datos. A proba está na propia carga útil do JWT.

Detectado — que facer na primeira hora

Unha clave de rol de servizo filtrada é unha emerxencia en tempo de execución. Asume que a clave foi raspada — os atacantes vixían os bundles públicos en tempo real. Trata a base de datos como comprometida ata que rotaras a clave e auditaras a actividade recente.

1. Rota a clave inmediatamente. No Panel de Supabase, vai a Configuración do proxecto → API → Clave de rol de servizo → Restablecer. A clave antiga inválidase en segundos. Calquera código do lado do servidor que use a clave debe actualizarse e redesplegarse antes de que a rotación se aplique.
2. Audita a actividade recente da base de datos. Abre Base de datos → Rexistros no panel. Filtra polos últimos 7 días. Busca consultas inusuais SELECT * contra táboas con PII, sentenzas grandes UPDATE ou DELETE e solicitudes desde IPs fóra da túa infraestrutura coñecida. Supabase rexistra a cabeceira x-real-ip en cada solicitude.
3. Comproba os obxectos de almacenamento. Visita Almacenamento → Rexistros e revisa as descargas de ficheiros recentes. Unha clave de rol de servizo filtrada dá acceso saltar-todo a buckets privados tamén.
4. Elimina a clave do control de fontes. Mesmo despois da rotación, deixar o JWT no historial de git significa que é descubrible no repositorio público. Usa git filter-repo ou BFG Repo-Cleaner para limpalo do historial e despois fai force-push (avisa primeiro aos colaboradores).
5. Reescanea despois da corrección. Executa un novo escaneo de FixVibe contra a aplicación redesplegada. O achado de segredos no bundle debería desaparecer. Confirma que non queda ningún JWT service_role nin cadea sb_secret_* en ningún chunk.

Previr a fuga desde o principio

A solución estrutural é disciplina de nomeamento máis garantías a nivel de ferramenta:

• Nunca prefixes a clave de servizo con NEXT_PUBLIC_*, VITE_*, nin ningún outro prefixo que cause incrustación no bundle. A convención de nomes é a fronteira — todos os frameworks respéctana.
• Mantén a clave de servizo totalmente fóra de .env na máquina do desenvolvedor. Lela dun xestor de segredos (Doppler, Infisical, variables de contorno cifradas de Vercel) no despregamento, nunca a confirmes localmente.
• <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.
• Engade unha barreira de CI que escanee a saída de compilación. Despois de next build, busca con grep no .next/static/chunks/ a cadea service_role. Fai fallar a compilación se atopa algo.

# 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

Preguntas frecuentes

Próximos pasos

Executa un escaneo de FixVibe contra o teu URL de produción — a comprobación de segredos no bundle é gratuíta, sen rexistro, e informa da exposición de service_role en menos dun minuto. Empareja isto co artigo Escáner de RLS de Supabase para verificar que a capa RLS estea facendo o seu traballo, e con Lista de comprobación de seguranza de buckets de almacenamento de Supabase para bloquear o acceso a ficheiros. Para o fondo de por que as ferramentas de IA xeran esta clase de fuga de forma tan fiable, le Por que as ferramentas de codificación con IA deixan fendas de seguranza.