¿Encontraste tu clave secreta de Supabase en el navegador? Qué hacer en la primera hora

Buscaste service_role o sb_secret_ en el JavaScript de tu app, como en nuestra revisión de Supabase en 10 minutos, y apareció. O alguien te escribió para avisarte. En cualquier caso, la clave que ignora todas las reglas de seguridad de tu base de datos es pública.

Es el error más grave con el que puede salir una app hecha con IA, y también uno de los más comunes. La buena noticia: la corrección lleva más o menos una hora si se hace en el orden correcto.

Por qué esta clave es distinta #

Supabase da a cada proyecto dos tipos de clave:

Con la clave secreta, un desconocido no necesita encontrar un hueco en tus reglas. Puede leer todas las tablas, cambiar cualquier fila, borrar datos y descargar archivos del storage privado. Tus reglas sencillamente no se le aplican.

Minutos 0–10: averigua qué clave se filtró #

Abre Project Settings → API Keys en el panel de Supabase y compáralo con lo que encontraste en el navegador:

• Si empieza por sb_secret_, es una de las nuevas claves secretas. Puedes reemplazarla sola, sin tocar nada más.
• Si es un token largo que empieza por eyJ, es la antigua clave service_role. Las claves antiguas no se pueden rotar de una en una, así que el camino es otro (más abajo).

Anota también dónde se usaba la clave: qué archivo, qué función de la app. Las herramientas de IA suelen ponerla en el frontend porque algo falló con la clave pública, normalmente una regla de RLS que faltaba, y el atajo fue la clave que ignora RLS.

Minutos 10–30: reemplaza la clave #

Si es una clave secreta nueva (sb_secret_) #

1. En API Keys, crea una nueva clave secreta y ponle un nombre que diga dónde se usará (por ejemplo, edge-functions).
2. Coloca la clave nueva en todos los sitios donde la necesita el código de servidor: secrets de las Edge Functions, variables de entorno del hosting, tareas en segundo plano.
3. Elimina la clave filtrada. Las solicitudes que la usan empiezan a fallar al instante.

Si es la antigua clave service_role #

1. Crea una clave publicable y una clave secreta en la página API Keys, si aún no las tienes.
2. Cambia en el frontend la clave anon por la publicable, y en el código de servidor la service_role por la secreta. Despliega.
3. Desactiva las claves de API antiguas en la misma página. Esto apaga a la vez la anon y la service_role, y por eso el paso 2 va primero. Supabase permite reactivarlas si se te pasó algún cliente, así que este paso es reversible.

Supabase está retirando las claves antiguas de todos modos, así que es un trabajo que tendrías que hacer pronto igualmente.

Minutos 30–45: saca la clave del frontend para siempre #

Reemplazar la clave corta la fuga; el código que la necesitaba ahora va a fallar. No lo arregles volviendo a poner la nueva clave secreta en el navegador. Lleva ese trabajo al servidor:

• Una Edge Function de Supabase para la acción que necesitaba acceso elevado (enviar una invitación, escribir en una tabla de administración, llamar a una API de pago). Las Edge Functions leen las claves secretas del proyecto desde su entorno, sin que tengas que pegarlas en el código.
• O una regla de RLS que permita exactamente lo que necesita la pantalla. Muchas veces la IA recurrió a la clave secreta por una tabla con RLS activado y sin ninguna regla para el usuario que inició sesión. La regla correcta hace innecesaria la clave secreta.

Después, vuelve a buscar en el JavaScript generado sb_secret_, service_role y los primeros caracteres de tu clave nueva. El objetivo es cero resultados.

Minutos 45–60: revisa qué pasó mientras estuvo expuesta #

Necesitas saber si alguien usó la clave, y para eso necesitas los logs mientras todavía existan.

• En Logs, en el panel, mira las solicitudes a la API durante el periodo de exposición: volúmenes inusuales, solicitudes a tablas que tu app nunca lee, descargas masivas con select=*, borrados que no hiciste tú.
• Revisa en Auth → Users si hay cuentas que no reconoces, y en el storage si hay archivos que no subiste.
• Si sospechas que cambiaron tus datos, comprueba qué copias de seguridad o recuperación point-in-time incluye tu plan antes de cambiar nada más.

La retención de logs en Supabase depende del plan y puede ser corta, así que hazlo hoy, no la semana que viene.

Asegúrate de que no vuelva a pasar #

Las herramientas de IA repiten lo que ya han visto en tu proyecto. Unos pocos hábitos evitan una segunda filtración:

• Guarda las claves secretas solo en variables de entorno del servidor, nunca en variables que tu framework envía al navegador (en Vite, todo lo que empieza por VITE_ termina en el bundle; en Next.js, todo lo que empieza por NEXT_PUBLIC_).
• Usa una clave secreta por servicio, con su nombre, para que una filtración obligue a reemplazar solo una.
• Antes de cada publicación, busca sb_secret_ y service_role en el build. Lleva segundos.
• Cuando la IA proponga la clave secreta para que desaparezca un error, tómalo como señal de que falta una regla de RLS.

Si prefieres que alguien revise la app completa, con claves, reglas, storage y autenticación, nuestro Security Check gratuito la mira desde fuera, en modo de solo lectura, y te dice qué corregir primero.