Cómo mantener seguras las claves de API en tu app

Para mantener seguras las claves de API, guárdalas como secretos o variables de entorno en tu hosting, ú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 solo el permiso que necesita, establece límites de gasto en el proveedor y, si una clave llega a filtrarse, rótala —crea una nueva y elimina la antigua— en lugar de limitarte a ocultar dónde apareció.

Una clave de API es la 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 constructores de apps con IA son buenos conectando estas claves, pero no siempre tienen cuidado con adónde van a parar, así que esta guía explica cómo mantenerlas seguras y cómo comprobarlo.

Claves públicas frente a claves secretas

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

Si no estás seguro 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 deben ir en las variables de entorno o en los secretos de tu hosting. Tu código las lee por nombre en tiempo de ejecución (por ejemplo process.env.OPENAI_API_KEY), así que el valor nunca aparece en tus archivos. Para el contexto, consulta qué son las variables de entorno y los secretos.

Mueve cada clave de API del código a variables de entorno. Enumera cada clave que encontraste, 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 puede ser leído por un visitante: el código fuente de la página y los archivos JavaScript son visibles en las herramientas de desarrollador.

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 a OpenAI directamente desde el navegador. Pasa 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.

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

Paso 3: Comprueba que nada se filtra

No des por bueno que funcionó: comprueba la web en producción:

1. Abre la app publicada en un navegador.
2. Abre las herramientas de desarrollador y ve a las pestañas Sources o Network.
3. Busca en todos 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, muévela 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 específicos.
• Restricciones por dominio o IP para las 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: alguien podría automatizar tu función de IA miles de veces, por ejemplo.

• Establece 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 límite de peticiones (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 hayan 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 nueva clave.
4. Elimina 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. Ahora está 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 push.
• Una sola clave para todo. Usa claves separadas para pruebas y para producción, y para cada app.
• Sin límite de gasto. Una clave filtrada o abusada sin tope puede generar una factura grande antes de que lo notes.
• Ocultar en lugar de rotar. Una vez expuesta una clave, solo una clave nueva la soluciona.
• Claves en capturas de pantalla. Recorta o difumina los ajustes antes de compartirlos para pedir ayuda.

Lista de verificación

• Cada clave está guardada como secreto o variable de entorno, no en el código.
• Ningún archivo .env ni ninguna clave está subido a Git.
• Las claves secretas solo se usan 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 con alcance cuando 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 alguna vez ha sido rotada.

Mantener las claves seguras en Mythex

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

• 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.
• Configuración del proyecto → 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 publicarla 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 a continuación. Si alguna vez una clave aparece en el chat, rótala en el proveedor.

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

Preguntas