Service Role Key

Qué significa “Service Role Key” (explicación simple)

Service Role Key . Builders use this concept to reduce accidental exposure and keep sensitive operations behind clear authorization boundaries.

En resumen: si alguien puede acceder al recurso directamente (sin pasar por tu backend), el control real está en la base/Storage/RPC — no en tu UI.

Explicación técnica: cómo funciona Service Role Key en Supabase

La clave service_role es un “superpoder”: puede bypassar RLS y grants de cliente. Si aparece en el bundle del navegador, en variables públicas o en logs, la exposición es crítica. El objetivo es simple: service_role solo en servidor, con endpoints que implementen autorización explícita. Si hay sospecha de filtración, rotar la clave reduce el riesgo de abuso continuado.

Rutas de ataque y fallos comunes (Service Role Key)

• service_role en variables NEXT_PUBLIC o en el bundle del cliente.
• service_role filtrada en logs, errores o herramientas de tracking.
• Secretos mal configurados en CI/CD o entornos serverless.
• Reutilización de claves entre entornos (dev → prod).
• No rotar tras exposición sospechada.

Dónde mirar en tu proyecto (Supabase)

• Variables de entorno y configuración de build (todo lo público).
• Artefactos del build (bundle) y mapas de fuente.
• Logs del servidor y herramientas de error reporting.
• Código que crea clientes Supabase con service_role fuera del backend.

Cómo suele fallar Service Role Key en Supabase

Estos son patrones que aparecen una y otra vez en proyectos reales:

• Putting the service role into NEXT_PUBLIC env vars for quick debugging.
• Logging the key to console output or CI artifacts.
• Failing to rotate the key after suspect exposure.

Cómo detectar problemas de Service Role Key

El objetivo es comprobar el comportamiento real, no lo que “parece” en la UI.

• Busca patrones de claves en el repositorio y en artefactos desplegados.
• Revisa variables públicas expuestas al cliente.
• Audita logs para headers/URLs que incluyan credenciales.
• Confirma que endpoints privilegiados existen (no dependas del cliente).
• Si hay dudas: asume exposición y planifica rotación.

Cómo corregir Service Role Key (enfoque backend-only)

1. Mueve service_role al servidor (API routes/server actions) y elimina usos en cliente.
2. Rota la clave si hay riesgo de filtración y actualiza entornos.
3. Redacta secretos en logs y limita qué se registra en errores.
4. Revoca rutas de acceso directo y valida backend-only.
5. Añade un guardrail de build que detecte claves en el output.
6. Re-escaneo y monitorización.

Checklist de verificación (después de corregir)

1. No hay service_role en bundle, variables públicas ni logs.
2. Endpoints privilegiados funcionan y aplican autorización.
3. Acceso directo con credenciales de cliente no permite bypass.
4. Rotación aplicada en todos los entornos relevantes.
5. Checklist evita futuras filtraciones.

Prevención de drift (para que no vuelva)

• Regla: secretos solo en servidor; revisiones de PR para cualquier cambio de env vars.
• Rotación periódica y rotación inmediata tras incidente.
• Redacción/filtrado en logging y error reporting.

Ejemplos y por qué funcionan

Estos ejemplos muestran escenarios concretos, causa raíz y corrección:

• Service role leaked into browser bundle → /examples/service-role-key/service-role-leaked-in-browser-bundle — A service_role key in a public env var exposed the entire database to browsers.
• Service role rotation after exposure → /examples/service-role-key/service-role-rotation-after-exposure — Rotating the service_role key after suspect exposure reduces the blast radius for future leaks.

Úsalos para reconocer el patrón en tu propio esquema y repetir la verificación.

Enlaces relacionados (English canonical + templates)

• English canonical: Service Role Key → /glossary/service-role-key

Preguntas rápidas (auto‑evaluación)

Si respondes “sí” a cualquiera de estas preguntas, vale la pena priorizar este fix:

• ¿Puedo acceder al recurso con una llamada directa (sin pasar por mi backend)?
• ¿El control de acceso depende de la UI (botones/ocultar pantallas) en lugar de la base/Storage?
• ¿No tengo una verificación repetible que pueda ejecutar tras migraciones?
• ¿Hay diferencias entre dev/staging/prod que podrían reintroducir exposición (drift)?
• ¿Estoy usando políticas/grants amplios por “comodidad” y sin documentación?

El objetivo no es “hacerlo perfecto”; es reducir exposición con un cambio pequeño, verificable y repetible.

Notas culturales/idioma

Esta página está optimizada para consultas en Bosanski. Si necesitas máxima precisión técnica, usa también la página en inglés (canonical).

Resumen rápido (para llevar)

• Valida siempre con acceso directo: los atacantes no usan tu UI.
• Prefiere backend-only para recursos sensibles y usa verificación repetible.
• Después de cada migración, re-ejecuta checks para evitar drift.
• Mantén secretos server-only y revisa grants/políticas/buckets/EXECUTE con disciplina.

Plantilla de “enunciado de límite” (para documentar el fix)

Este enunciado te ayuda a dejar claro el modelo de acceso y a detectar regresiones:

• Solo el backend puede (operación) sobre (recurso) tras autorización explícita.
• El cliente no debe poder acceder directamente a (tabla/bucket/función) con credenciales anon/auth.
• Verificación: la llamada directa (describe la petición) debe fallar en dev/staging/prod.

Guardar este enunciado junto con la evidencia (antes/después) hace que revisiones y migraciones sean más seguras.

Mini ejemplo de verificación (sin SQL)

Si quieres una verificación rápida sin meterte en SQL, usa este enfoque:

1. Antes del fix, intenta una llamada directa desde el cliente (REST/RPC/Storage) y guarda el resultado.
2. Aplica el cambio (backend-only + revocar accesos amplios) y repite la misma llamada directa.
3. Confirma que ahora falla con una denegación clara, y que el backend autorizado sigue funcionando.
4. Repite en staging/prod para evitar el clásico “funciona en dev”.

Si estas cuatro líneas se cumplen, tu corrección es real y resistente a regresiones.

Plan operativo de 7 días (aplícalo sin bloquear producto)

Este plan está pensado para equipos pequeños que necesitan mejorar seguridad sin frenar entregas. La idea es hacer un cambio corto, verificable y repetible cada día, con foco en evidencia y no en teoría.

1. Día 1: identifica el recurso más sensible relacionado con este término y reproduce el riesgo con una llamada directa.
2. Día 2: crea o ajusta la ruta backend-only y documenta la regla de autorización en una frase.
3. Día 3: revoca el acceso directo amplio desde cliente (grants, bucket público o EXECUTE público, según aplique).
4. Día 4: ejecuta verificación en dev y staging con la misma prueba directa; debe fallar de forma consistente.
5. Día 5: repite en producción y guarda evidencia mínima (qué cambió, prueba usada, resultado esperado).
6. Día 6: añade guardrail post-migración (scan o checklist) para evitar drift silencioso.
7. Día 7: revisa una ruta relacionada (tabla, Storage o RPC) y repite el ciclo con menor fricción.

Si mantienes este ritmo semanal, reduces exposición real sin depender de “arreglos heroicos” de último minuto.

Siguiente paso

Si sospechas exposición en tu proyecto, ejecuta un escaneo y valida el acceso directo. Después aplica un template y verifica que el acceso desde el cliente ya no funcione.