Reeve Fundamentos de seguridad
Las nuevas claves de API de Supabase: ¿cuál va en tu app?
Supabase sustituyó anon y service_role por claves publicables y secretas. ¿Cuál pertenece a tu app y cuál no debe estar nunca?
En resumen
- Supabase ahora emite claves sb_publishable_ y sb_secret_. Sustituyen a anon y service_role y hacen exactamente los mismos dos trabajos.
- La clave publicable pertenece a tu app. La secreta nunca, y ahora las distingues leyendo los primeros caracteres.
- Tus claves antiguas siguen funcionando hoy. Supabase ha dicho que todos los proyectos tendrán que dejarlas a finales de 2026.
Si has abierto tu panel de Supabase hace poco y has encontrado claves que
empiezan por sb_publishable_ y sb_secret_ donde antes estaban anon y
service_role, no se ha roto nada. Supabase ha cambiado el nombre de sus claves
de API, y el par que conocías está de salida.
El cambio es pequeño en lo que hace y grande en lo que evita. Las dos claves siguen cumpliendo exactamente los dos trabajos de siempre. Lo nuevo es que ahora ves cuál es cuál sin abrir nada.
Qué ha cambiado Supabase en realidad
Supabase anunció las nuevas claves en julio de 2025, junto con un cambio en cómo firma los tokens de sesión. Dos cosas sustituyeron a otras dos:
- La clave publicable,
sb_publishable_…, sustituye a la claveanon. - Las claves secretas,
sb_secret_…, sustituyen a la claveservice_role.
Los permisos no cambian. Una clave publicable sigue identificando tu proyecto y no lleva permisos propios; una secreta sigue saltándose todas las reglas que has escrito. Si ya sabes qué claves son seguras en un frontend, nada de esa intuición ha quedado obsoleta.
Merece la pena conocer dos diferencias prácticas. Puedes tener varias claves secretas a la vez y revocarlas de una en una, así que rotar una clave ya no implica un momento en el que se rompe todo lo que la usaba. Y las claves antiguas tenían una propiedad que casi nadie notó: eran JWT que caducan diez años después de crear el proyecto. Las nuevas no llevan caducidad dentro.
Cuál de las dos pertenece a tu app
La publicable, y solo la publicable.
Tu app se ejecuta en el navegador de tu visitante, y la petición a tu base de
datos sale desde ahí. Tiene que decir a qué proyecto pertenece, y ese
identificador llega a cada visitante por diseño. sb_publishable_… es la clave
construida para eso: encontrarla en tu app no es un hallazgo, y nunca lo fue.
sb_secret_… es lo contrario. Lee y escribe cada fila de cada tabla desde donde
sea, ignorando por completo tus políticas, que es justo su propósito. Su sitio es
un servidor, una edge function, un worker: ningún lugar al que llegue un
navegador. Si alguna vez se ha pegado una en el código del frontend, renuévala en
el panel antes de tocar nada más, porque borrar la línea no cierra la puerta.
Cómo saber cuál tienes
Lee los primeros caracteres. Esa es ya toda la comprobación.
| Lo que ves | Qué es | ¿Segura en el navegador? |
|---|---|---|
sb_publishable_… | clave publicable actual | Su sitio |
sb_secret_… | clave secreta actual | Nunca |
eyJ… con anon | clave publicable antigua | Su sitio |
eyJ… con service_role | clave secreta antigua | Nunca |
Una clave actual es una cadena larga en dos mitades: un centro aleatorio y una
suma de verificación corta al final. Una clave antigua son tres bloques
separados por puntos, y el del medio es texto legible en vez de cifrado, y por eso
distinguir el par antiguo pasaba por descodificarlo y leer el campo role.
Si encuentras una clave en tu app y no sabes cuál es, nuestro escaneo gratuito lee tu web en vivo desde fuera y nombra lo que puede ver. Tarda unos 20 segundos y no necesita cuenta: escanea tu app.
¿Mis claves anon y service_role antiguas siguen funcionando?
Hoy sí. Supabase ha publicado un calendario, no un interruptor:
| Cuándo | Qué pasa |
|---|---|
| 1 de noviembre de 2025 | Los proyectos restaurados después de esa fecha ya no reciben anon ni service_role. |
| Finales de 2026, sin fecha fija | Todos los proyectos tendrán que usar las claves nuevas. |
Así que no hay emergencia esta semana, y sí hay una fecha límite este año. Si tu app se construyó antes del cambio de nombre y no se ha tocado desde entonces, ahora mismo funciona con claves antiguas y seguirá haciéndolo un tiempo.
El motivo para moverse pronto no es la fecha límite. Es el día en que alguien
pega la clave equivocada en un prompt: sb_secret_ se delata, eyJ… no.
Cómo cambiar sin romper tu app
La guía de migración de Supabase es la referencia. La versión corta, para una app que no escribiste a mano:
- En el panel, abre Settings → API Keys y crea las claves nuevas. Eso las añade; no quita las antiguas, y los dos pares funcionan a la vez.
- Busca dónde crea tu app su cliente de Supabase y sustituye la clave publicable. En un builder como Lovable o Bolt suele ser un valor en los ajustes del proyecto y no una línea de código.
- Sustituye la clave secreta allí donde se use en un servidor: edge functions, webhooks, tareas programadas, cualquier cosa que no sea el navegador.
- Carga tu app y recorre las partes que leen y escriben datos. Una clave publicable equivocada falla de inmediato y en voz alta, que es el caso bueno.
- Solo cuando todo funcione, desactiva las claves antiguas.
El paso 5 es el que hay que dejar para el final, y conviene hacerlo a propósito
en vez de nunca: los proyectos a medio migrar, donde la app todavía lleva una
clave anon vieja junto a una sb_publishable_ viva, son comunes y confusos de
depurar.
Qué hacer esta semana
Qué hacer
- Abre Settings → API Keys y mira qué pares tiene tu proyecto. Es un minuto y te dice en qué punto estás.
- Si encuentras
sb_secret_…oservice_roleen cualquier parte del código del frontend, renuévala hoy. Es el único punto urgente de esta lista. - Crea las claves nuevas y pasa tu app cuando tengas media hora, no por la fecha límite sino porque el prefijo hace obvio el próximo error.
- Aprovecha para mirar Row Level Security. La clave nueva no cambia nada de lo que permiten tus políticas, y activar RLS no es lo mismo que estar protegido.
Si quieres la versión concreta de qué revisar en tu plataforma, tenemos una guía en lenguaje claro para apps con Supabase, y la lista de seguridad en 10 minutos cubre esto junto a las demás cosas que conviene desactivar en una app recién lanzada.
Preguntas frecuentes
¿sb_publishable_ es lo mismo que la clave anon?
Hace el mismo trabajo. Nombra tu proyecto para que una petición sepa a dónde ir, no lleva permisos propios y está pensada para vivir en tu app, donde cualquiera puede leerla. Lo que protege tus datos en ambos casos es Row Level Security, no la clave.
¿Mis claves anon y service_role siguen funcionando?
Sí, hoy. Supabase las ha mantenido en marcha durante la migración y puedes tener los dos pares a la vez. Lo anunciado es que a finales de 2026 todos los proyectos deberán pasar a las nuevas claves, sin fecha exacta todavía.
Tengo los dos pares en el panel. ¿Cuál debe usar mi app?
La publicable, sb_publishable_. El cambio es de una línea: sustituye la clave que tu app pasa cuando crea el cliente de Supabase. Nada cambia en tus tablas ni en tus políticas, porque la clave nueva tiene exactamente los permisos que tenía la anon.
¿El nuevo formato hace mi app más segura por sí solo?
No. Hace que la clave peligrosa se vea a simple vista, y eso vale dinero en errores no cometidos, pero una clave publicable sigue leyendo todo lo que tus políticas le permitan. Si Row Level Security está apagado, la clave nueva abre tu base de datos exactamente igual de par en par que la antigua.