Dónde están tus claves API de Supabase: anon, service_role y URL

Algo te ha pedido tu clave de Supabase. Una guía de instalación, un hilo de soporte, o una IA a la que le dijiste que arreglara tu app. Abres el panel, encuentras una página con una dirección y dos o tres claves con nombres como anon y service_role, y todas parecen poder ser la respuesta.

O es la otra versión de esto. Alguien abrió tu sitio, pulsó F12 y te dijo que una clave estaba expuesta. Ahora quieres mirar la clave que encontró, y no sabes dónde vive.

La mayoría de las guías empiezan en la página de claves API. Eso da por hecho que ya sabes cuál es tu proyecto de Supabase, y ese es precisamente el paso que un builder hizo por ti y nunca te explicó.

¿Dónde están las claves API de Supabase?

En el panel, dentro de tu proyecto, en Settings → API Keys.

El camino completo: entra en supabase.com, elige tu proyecto de la lista, abre Settings en la barra lateral izquierda y luego API Keys. Casi todas las guías y capturas que encuentres llaman a esa página Settings → API, porque así se llamaba hasta hace poco. Es la misma página y son los mismos valores.

Todo lo que hay en ella es una de dos cosas. Una dirección, que dice dónde vive tu proyecto. O una clave, que decide qué puede hacer una petición una vez llega. La página las lista juntas, en una sola columna, con la misma tipografía.

Nunca configuré Supabase. ¿Cuál es mi proyecto?

Lee la dirección que tu app ya está usando. La respuesta está dentro.

Cada proyecto de Supabase tiene una referencia: una cadena corta y aleatoria que además es la primera parte de la dirección del proyecto, https://yourreference.supabase.co. Tu app envía una petición a esa dirección en cada carga de página, así que la cadena ya está en tu app, y es la misma con la que el panel identifica tu proyecto.

Tres sitios donde encontrarla sin preguntar a nadie:

• En tu builder. Lovable, Bolt, v0 y los demás muestran el proyecto de Supabase conectado en algún lugar de los ajustes o del panel de integraciones de tu proyecto.
• En tu navegador. Abre tu app en producción, pulsa F12, ve a la pestaña Network y recarga la página. Las peticiones que salen hacia algo con .supabase.co llevan la referencia en su dirección.
• En el código fuente de la página, si tu app escribe la dirección en el HTML en lugar de en un archivo de script.

Después entra en supabase.com y compara esa referencia con tu lista de proyectos. Los builders conectan Supabase a través de tu propia cuenta, así que el proyecto suele estar en un panel en el que te registraste una vez y nunca usaste. Una vez dentro de un proyecto la referencia aparece en la barra de direcciones del navegador, y así confirmas que estás en el correcto antes de copiar nada de él.

Las cuatro cosas de esa página

Una dirección y tres claves. Dos van en tu app y dos no salen nunca del panel.

Hay un atajo en la propia página. Supabase imprime la URL del proyecto y la clave publicable donde puedes leerlas, y cubre la clave secreta y el valor JWT con puntos hasta que pides verlos. Los dos que tapa son justo los dos que nunca van en tu app.

¿Dónde está la URL de mi proyecto de Supabase?

En dos sitios, y probablemente ya tengas uno delante. El panel la imprime arriba del todo en Settings → API Keys, con la etiqueta Project URL. La barra de direcciones de tu navegador muestra esa misma cadena cada vez que tu app habla con Supabase, con la forma https://yourreference.supabase.co.

En el código lleva uno de tres nombres, y los tres guardan esa misma cadena:

• VITE_SUPABASE_URL en una app construida con Vite, que cubre la mayoría de lo que producen Lovable y Bolt
• NEXT_PUBLIC_SUPABASE_URL en una app de Next.js
• SUPABASE_URL en un servidor, en una edge function o en un script

El trozo del medio, yourreference, es la referencia de tu proyecto. Es la cadena por la que el panel identifica tu proyecto, y la que hay que comparar cuando tienes varios proyectos y ni idea de cuál pertenece a esta app.

Es una dirección más que un secreto, y por eso está a la vista junto a la clave publicable.

¿Dónde está la clave service_role, y qué es SUPABASE_SERVICE_ROLE_KEY?

En la misma página que todo lo demás. Abre Settings → API Keys y busca la fila service_role, o secret en un proyecto creado hace poco. A diferencia de la URL y la clave publicable, su valor queda detrás de un control de revelado hasta que lo pides.

Ese control es la única pista que te da el panel de que esta es distinta, y merece tomarse en serio: Supabase tapa exactamente los valores que nunca deben llegar a un navegador.

SUPABASE_SERVICE_ROLE_KEY es un nombre de variable más que una segunda clave: detrás está el valor que acabas de revelar. Te lo encontrarás en un archivo .env, en los ajustes de entorno de tu hosting, o en los secretos de una edge function. Lo que importa es el prefijo que lleva delante. Una variable llamada VITE_SUPABASE_SERVICE_ROLE_KEY o NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY se compila dentro del JavaScript que descargan tus visitantes, así que la clave es pública en cuanto despliegas. Esos prefijos son instrucciones de publicar, no descuidos.

Donde sí encaja es en una edge function, un manejador de webhooks, una tarea programada o un script de migración: en cualquier sitio donde el código corra en una máquina que controlas y ningún visitante pueda abrir el archivo. Esta es la clave que ignora Row Level Security por completo, así que lee cada fila de cada tabla digan lo que digan tus reglas.

Si no tienes claro que la tuya se quedó en el servidor, nuestro escáner de seguridad web gratis lee tu sitio en vivo desde fuera y nombra las claves que encuentra, en unos 20 segundos.

¿Qué clave necesita mi app?

La URL del proyecto y la clave publicable. Nada más, nunca.

Tu app se ejecuta en el navegador de tus visitantes y habla con Supabase desde ahí, así que esos dos valores viajan a cada visitante por diseño. Eso no es una filtración y nunca lo fue. Lo que impide que un desconocido lea toda tu base de datos con una clave publicable es Row Level Security: las reglas que deciden, fila a fila, quién puede ver qué.

Así que esas reglas son lo que hay que revisar cuando te preocupas, y activarlas no es lo mismo que estar protegido. La versión larga de por qué una clave es segura en público está en qué claves API son seguras en tu frontend.

¿Cómo sé qué clave llevó realmente mi app?

Desde el panel no puedes saberlo. Lista las claves que tiene tu proyecto, no la que acabó dentro de tu app.

Son dos preguntas distintas, y solo la segunda puede hacerte daño. Un proyecto puede tener una página de ajustes completamente normal y aun así tener su clave secreta pegada en un archivo que cualquiera puede abrir. Para responderla hay que leer la clave que está de verdad en la app.

En un proyecto nuevo, lee los primeros caracteres. sb_publishable_ es la que va ahí. sb_secret_ es la que hay que atender hoy.

En un proyecto antiguo, tienes que mirar dentro de la clave. anon y service_role son JWT: tres bloques separados por puntos, y el del medio se descodifica en texto perfectamente legible. Lleva un campo role, y esa sola palabra es toda la diferencia entre las dos. Cómo leerlo.

Si prefieres no revisar tu app a mano, nuestro escaneo gratuito lee tu sitio en producción desde fuera y nombra las claves que ve, además de si tus tablas responden a un desconocido que pregunta. Tarda unos 20 segundos y no necesita cuenta: escanear tu app.

¿Y si la clave secreta ya está en mi app?

Ocúpate de la clave antes de tocar nada de código, y en Supabase eso puede que no signifique lo que esperas.

El consejo habitual es rotar: generas una clave nueva, revocas la vieja y el valor que se filtró deja de funcionar. Eso sigue valiendo para las claves nuevas. Un proyecto puede tener varias claves sb_secret_ a la vez y revocarlas de una en una, así que sustituir una ya no implica un minuto en el que todo lo que la usaba está roto.

Para el par original no vale en absoluto. Las propias notas de resolución de problemas de Supabase dicen que ya no es posible rotar los antiguos secretos anon, service_role y JWT. Inutilizar una clave service_role antigua que se ha filtrado pasa por crear las claves nuevas, mover tu app y tu código de servidor a ellas, y después desactivar el par viejo. Lo que implica esa migración son unos cuantos pasos en el panel y un valor cambiado en tu app, bastante más llevadero una tarde tranquila que el día en que lo necesitas.

Qué hacer ahora

Si prefieres recorrer esto como una lista, la checklist de seguridad de 10 minutos cubre esto y las otras cosas que conviene apagar en una app recién lanzada, y tenemos una guía en lenguaje claro para apps de Supabase.