Cómo mantener a salvo las claves de API en tu app

Para mantener a salvo las claves de API, guárdalas como secretos o variables de entorno en tu alojamiento, úsalas solo en código del servidor y nunca las pegues en el chat, en archivos de código, en capturas de pantalla ni en un repositorio de Git. Da a cada clave el mínimo permiso que necesite, configura límites de gasto en el proveedor y, si una clave se filtra, rótala: crea una nueva y borra la antigua, en lugar de limitarte a ocultar dónde apareció.

Una clave de API es una contraseña de un servicio. Tu clave de OpenAI permite a alguien gastar tu dinero en IA; tu clave secreta de Stripe permite emitir reembolsos; tu clave del proveedor de correo permite enviar correos en tu nombre. Los creadores de apps con IA son buenos conectando estas claves, pero no siempre son cuidadosos con el lugar donde acaban, así que esta guía explica cómo protegerlas y cómo comprobarlo.

Claves públicas y claves secretas

No todas las claves son secretas. Saber la diferencia evita que te preocupes por la clave equivocada e ignores la correcta.

Si no sabes de qué tipo es una clave, consulta la documentación del proveedor. En caso de duda, trátala como secreta.

Paso 1: guarda las claves como secretos, no en el código

Las claves pertenecen a las variables de entorno o a los ajustes de secretos de tu alojamiento. Tu código las lee por su nombre en tiempo de ejecución (por ejemplo process.env.OPENAI_API_KEY), así que el valor nunca aparece en tus archivos. Para más contexto, consulta qué son las variables de entorno y los secretos.

Mueve todas las claves de API del código a variables de entorno. Haz una lista de cada clave que encuentres, en qué archivo estaba y el nombre de variable que usaste. No me muestres los valores.

Después comprueba que no queda ninguna:

Busca en todo el proyecto, incluidos los archivos de configuración y cualquier archivo .env, algo que parezca una clave de API o una contraseña. Indica el archivo y la línea, no el valor.

Paso 2: usa las claves secretas solo en el servidor

Esta es la regla más importante. Todo lo que recibe el navegador, cualquier visitante puede leerlo: el código fuente de la página y los archivos JavaScript son visibles en las herramientas de desarrollo.

Así que si la app necesita llamar a OpenAI, el navegador debe llamar a tu servidor, y tu servidor llama a OpenAI con la clave. La clave nunca sale del servidor.

La función de chat llama directamente a OpenAI desde el navegador. Mueve esa llamada a una ruta de API del servidor que lea OPENAI_API_KEY del entorno. El navegador solo debe llamar a nuestra ruta. Exige inicio de sesión para la ruta.

Ojo con una trampa habitual en los frameworks de frontend: las variables con prefijo público, VITE_ en Vite o NEXT_PUBLIC_ en Next.js, se incluyen a propósito en el código del navegador. Una clave secreta con uno de esos prefijos queda expuesta, aunque esté «en una variable de entorno».

Paso 3: comprueba que no se filtra nada

No des por hecho que funcionó; comprueba la web publicada:

1. Abre la app publicada en un navegador.
2. Abre las herramientas de desarrollo y la pestaña Sources o Network.
3. Busca en los archivos los primeros caracteres de cada clave secreta (por ejemplo sk_ o sk-).
4. Revisa las peticiones de red que hace la app. Una petición que va directamente del navegador a un proveedor de IA de pago es una señal de alarma.

Si encuentras una clave secreta, pásala al servidor (paso 2) y rótala (paso 6), porque ya era pública.

Paso 4: restringe lo que puede hacer cada clave

Muchos proveedores permiten limitar una clave:

• Claves con alcance o restringidas, que solo pueden hacer lo que necesita tu app. Stripe, por ejemplo, admite claves restringidas con permisos concretos.
• Restricciones por dominio o por IP para claves que deben ser públicas, como las de mapas.
• Claves separadas por app y por entorno, para que una filtración no exponga todo y revocar una no rompa las demás.
• Claves de prueba mientras construyes y claves reales solo en la app publicada.

Paso 5: pon un techo al daño

Incluso una clave bien protegida puede usarse mal a través de tu propia app; por ejemplo, alguien que lanza tu función de IA miles de veces con un script.

• Configura límites de gasto o alertas en cada proveedor de pago.
• Exige inicio de sesión para cualquier función que cueste dinero por llamada.
• Añade un límite de frecuencia por usuario. Consulta qué es el limitador de frecuencia (rate limiting).

Añade un límite de 30 peticiones de IA por usuario y por hora a /api/chat. Devuelve un mensaje claro cuando se alcance el límite. Rechaza las peticiones de usuarios que no han iniciado sesión.

Paso 6: rota las claves que se filtren

Si una clave secreta aparece donde no debía (un mensaje de chat, un commit, una captura de pantalla, un ticket de soporte, código del navegador), da por hecho que está comprometida.

1. Crea una clave nueva en el proveedor.
2. Actualiza el secreto en los ajustes de tu app.
3. Vuelve a desplegar o a publicar para que la app en producción use la clave nueva.
4. Borra la clave antigua en el proveedor.
5. Revisa los registros de uso del proveedor por si hay actividad que no reconoces.

Borrar el mensaje del chat o el commit de Git no basta. El historial de Git conserva las versiones antiguas, y lo que fue público puede haberse copiado.

Errores habituales

• Pegar una clave en el prompt. Ya queda en el historial del chat. Usa un formulario de secretos.
• Un prefijo público en una variable secreta. VITE_OPENAI_API_KEY envía la clave a todos los visitantes.
• Subir un archivo .env a Git. Asegúrate de que está en .gitignore antes del primer envío.
• Una sola clave para todo. Usa claves separadas para pruebas y producción, y para cada app.
• Ningún límite de gasto. Una clave filtrada o abusada sin tope puede generar una factura enorme antes de que lo notes.
• Ocultar en lugar de rotar. Una vez expuesta una clave, solo una clave nueva la arregla.
• Claves en capturas de pantalla. Recorta o difumina los ajustes antes de compartirlos para pedir ayuda.

Lista de comprobación

• Cada clave está guardada como secreto o variable de entorno, no en el código.
• Ningún archivo .env ni ninguna clave están subidos a Git.
• Las claves secretas se usan solo en código del servidor.
• Ninguna variable secreta usa un prefijo público como VITE_ o NEXT_PUBLIC_.
• He buscado en el JavaScript de la web publicada el prefijo de cada clave y no he encontrado nada.
• Las claves están restringidas o limitadas donde el proveedor lo permite.
• Las claves de prueba y las reales están separadas.
• Las funciones de pago exigen inicio de sesión y tienen límites por usuario.
• Cada proveedor de pago tiene un tope de gasto o una alerta.
• Sé cómo rotar cada clave, y cualquier clave que haya estado expuesta ha sido rotada.

Mantener las claves a salvo en Mythex

Mythex mantiene las claves fuera de tu código y del chat de dos maneras:

• Tarjeta de solicitud de secretos. Cuando el agente necesita una clave, muestra una tarjeta en el chat donde introduces el valor en campos de formulario, no en el cuadro de mensaje, y se guarda como secreto del proyecto. Consulta Secretos en el chat.
• Ajustes del proyecto → Secrets (Secretos), o /secrets en el chat, para añadir o cambiar claves tú mismo. Consulta Variables de entorno y secretos.

Tras cambiar un secreto de una app publicada, vuelve a publicar para que la app en producción lo recoja. Los proyectos exportados no incluyen los secretos, así que vuelve a añadirlos donde ejecutes el código. Si alguna vez una clave aparece en el chat, rótala en el proveedor.

Para el resto de la revisión de seguridad antes del lanzamiento, sigue la lista de comprobación de seguridad para apps creadas con IA. Si vas a añadir funciones de IA, cómo usar las API de LLM explica con más detalle las claves y los costes.

Preguntas