Claves de API y variables de entorno en un IDE de navegador

La primera regla es incómoda pero sencilla: una aplicación web estática no puede guardar un secreto. El navegador descarga HTML, CSS y JavaScript, y después los ejecuta en la máquina del usuario. Cualquiera puede abrir DevTools, revisar el panel de red, buscar en el bundle o poner un punto de interrupción e inspeccionar una variable. Minificar el código, dividirlo en fragmentos u ocultar un valor en un archivo de configuración cambia el esfuerzo, no el resultado. Un IDE de navegador añade un sandbox para ejecutar el código del proyecto, pero la interfaz del propio IDE sigue ejecutándose en el mismo origen y debe leer lo que necesita para funcionar. El sandbox no es una caja fuerte para los valores que la propia interfaz tiene que usar. La prueba útil es directa: si un valor debe estar disponible para el código que se ejecuta en la pestaña, asume que la persona que usa la pestaña puede leerlo, y que cualquier script que se ejecute en el mismo origen también puede leerlo. Eso no hace inseguro el desarrollo en el navegador. Define el límite. Los identificadores públicos pueden vivir ahí; las credenciales de servidor, no.

En un servidor Node.js, una variable de entorno se lee en tiempo de ejecución desde el proceso. En una compilación de Vite, Create React App, Next.js o Astro, las variables de entorno públicas funcionan de otra manera: el bundler sustituye las referencias por cadenas literales durante la compilación. Vite expone las variables con prefijo VITE_ mediante import.meta.env; Create React App usa REACT_APP_; Next.js usa NEXT_PUBLIC_; Astro usa PUBLIC_. El prefijo es una convención de nombres, no un control de seguridad. Una vez que un valor se inserta en el código, forma parte del JavaScript que descarga cada visitante. Una variable sin prefijo público normalmente no está disponible para el código del cliente, y por eso los valores exclusivos del servidor deben leerlos un servidor o una función serverless, no una página estática. Un archivo .env es una entrada de desarrollo y compilación, no un almacén de secretos en tiempo de ejecución. Sirve para la configuración local y para mantener valores fuera del control de versiones, pero no vuelve privado un valor después de la compilación.

# Safe to expose: a public endpoint
VITE_API_URL=https://api.example.com

# Never expose: keep this on a server
STRIPE_SECRET_KEY=REPLACE_WITH_SERVER_SECRET

Algunas claves están diseñadas para ser públicas. Una clave publicable de Stripe identifica una cuenta y crea tokens de pago; la clave secreta es la que mueve dinero y debe quedarse en un servidor. Una clave anónima de Supabase solo es segura cuando las políticas de seguridad a nivel de fila son correctas. La configuración web de Firebase identifica un proyecto, pero no concede acceso administrativo. Las claves de mapas y analítica suelen restringirse por dominio o por API. Estos valores pueden llegar al navegador, pero aun así merecen límites: orígenes permitidos, restricciones de API, roles con privilegios mínimos, cuotas y alertas. La categoría opuesta es más fácil de enunciar. Las claves con rol de servicio, las contraseñas de bases de datos, las credenciales SMTP, los secretos de firma y las claves privadas de proveedores de IA nunca deben estar en un bundle estático. Una clave de proveedor que pertenece a la aplicación es especialmente peligrosa: cualquiera que la encuentre puede gastar el dinero de la aplicación. Una clave que pertenece al usuario es otro caso. Sigue siendo una credencial de portador, pero es suya, y el objetivo es mantenerla en su navegador y no en el proyecto ni en el repositorio.

El panel de IA de GB Coder funciona con tu propia clave (BYOK). El gestor de claves mantiene las claves de proveedor en memoria por defecto. No las escribe en localStorage. El usuario puede optar explícitamente por persistirlas en sessionStorage, lo que limita el valor a la pestaña actual y normalmente lo borra al cerrarla. La clave se elimina de la memoria y del almacenamiento de sesión cuando el usuario la borra. El gestor también vincula cada clave a un origen de endpoint autorizado, y una puerta de salida comprueba que una credencial no se envíe a un destino para el que no fue aprobada. Los errores de los proveedores pasan por una capa de redacción que elimina patrones de claves y claves activas antes de que el mensaje llegue a la interfaz o a un log. Los metadatos de proveedores personalizados se guardan en localStorage, pero las cabeceras marcadas como secretas se limpian antes de persistir y deben volver a introducirse. Las peticiones van directamente del navegador al endpoint del proveedor; GB Coder no actúa como proxy de la clave a través de un servidor de LadeStack. Estas medidas reducen la persistencia accidental y las fugas entre orígenes. No cambian la regla básica: cualquier script que pueda ejecutarse en el mismo origen puede leer lo que puede leer la página. Usa un perfil limpio para trabajo sensible y no instales extensiones que no confíes.

Mantén los secretos fuera del árbol del proyecto. Añade .env y sus variantes locales a .gitignore, y confirma un .env.example con nombres de marcador de posición. Si un proyecto usa Vite, recuerda que cada variable VITE_ se inserta en el bundle de producción. Un valor que era cómodo durante el desarrollo local se vuelve público en el momento en que se usa en una compilación de producción. Antes de desplegar, inspecciona los recursos generados en busca de patrones de claves y trata cualquier hallazgo como un incidente, no como una advertencia. El escaneo de secretos y la protección de push de GitHub pueden detectar algunos formatos de token conocidos, pero son una red de seguridad, no un sustituto de mantener los valores fuera del repositorio. La exportación ZIP de un IDE de navegador incluye los archivos del proyecto. Si hay un archivo .env dentro del proyecto, viaja con la copia de seguridad. Una copia de seguridad no es una caja fuerte cifrada. Guarda las exportaciones en un lugar privado y elimina las copias antiguas cuando ya no las necesites. Lo mismo se aplica a capturas de pantalla, informes de incidencias y mensajes de chat: una clave pegada en cualquiera de ellos ya salió del navegador.

# .gitignore
.env
.env.local
.env.*.local

Los tokens de acceso personal de GitHub y los tokens de despliegue son más poderosos de lo que parecen. Un token clásico con permisos de repositorio y flujo de trabajo puede leer código privado, cambiar archivos y activar releases. Prefiere tokens de grano fino con un solo repositorio, una lista explícita de permisos y una fecha de caducidad. Da a un token solo los permisos que necesita la tarea: lectura y escritura de contenidos para una sincronización, no administración ni facturación. Crea tokens separados para dispositivos o propósitos separados y revócalos cuando termines. Los tokens de despliegue de Vercel o Netlify pueden publicar, reemplazar o eliminar proyectos. Si el proveedor admite alcance por proyecto o equipo, úsalo; si admite caducidad, configúrala. Pega el token en el panel de despliegue solo cuando sea necesario y no lo guardes en un archivo del proyecto. En CI, usa secretos del repositorio u organización en lugar de un .env confirmado, y recuerda que las pull requests de forks normalmente no reciben secretos. Un token que se ha capturado en pantalla, compartido en un chat o confirmado en un repositorio público debe tratarse como comprometido aunque se haya borrado un segundo después.

Una clave de proveedor de IA es una credencial de portador con una factura adjunta. Cualquiera que la tenga puede enviar peticiones, consumir cuota y generar cargos. Usa una clave limitada a un proyecto, configura un límite de gasto si el proveedor lo ofrece y usa una clave separada para experimentos en lugar de la clave maestra de la organización. Revisa el uso con regularidad, sobre todo después de compartir un dispositivo o instalar una extensión nueva. Los proveedores locales como Ollama, LM Studio y vLLM no necesitan una clave en la nube, pero sus endpoints siguen siendo servicios de la máquina. No expongas un endpoint local a internet solo para que funcione una demo. Si un proveedor personalizado apunta a un proxy, el proxy puede ver la clave; usa solo un proxy que controles y entiendas. La inyección de prompts es un riesgo relacionado: un archivo, una página web o un mensaje de error pegado pueden contener instrucciones dirigidas al asistente. Mantén los secretos fuera de los prompts y de los archivos que el asistente tiene permitido leer. Si una clave aparece en una conversación, rótala.

Un equipo compartido o de laboratorio merece una rutina distinta. Usa un perfil de navegador privado, no optes por la persistencia de sesión y cierra la pestaña al terminar. Si el navegador ofrece guardar la clave, rechaza. Borra el almacenamiento del sitio si sospechas que se conservó. Las extensiones del navegador son otra parte del límite: una extensión con permisos amplios de host a menudo puede leer el contenido o el almacenamiento de la página, y una actualización maliciosa puede llegar después de instalarla. Usa un perfil mínimo para el trabajo con credenciales. El cross-site scripting es el riesgo web clásico en este contexto. Si un atacante puede ejecutar un script en el origen del IDE, ese script puede leer localStorage y sessionStorage y hacer peticiones mientras la página está abierta. Mantén las dependencias actualizadas, evita scripts de terceros que no confíes y considera una política de seguridad de contenido en el sitio desplegado. Los gestores de portapapeles y las herramientas para compartir pantalla también ven lo que copias y muestras. Limpia el portapapeles después de mover una clave y pausa la compartición antes de abrir un panel de configuración del proveedor.

La rotación es la única respuesta fiable a una clave filtrada. Revocar primero es importante: si la clave antigua sigue siendo válida mientras se prepara la nueva, la exposición continúa. Crea la nueva clave con el alcance más estrecho que funcione, actualiza la aplicación o la configuración del navegador, vuelve a desplegar si el valor formaba parte de una compilación y verifica que la clave antigua es rechazada. Después revisa el uso y los registros de auditoría del proveedor en busca de actividad que no esperabas. Si la clave se confirmó en Git, borrar el archivo no basta; el valor permanece en el historial. Rota primero, luego reescribe el historial con una herramienta como git filter-repo o BFG, haz force-push con el acuerdo del equipo y pide a los colaboradores que vuelvan a clonar. Las plataformas de hosting pueden cachear compilaciones antiguas, así que asegúrate de que el valor antiguo no pueda servirse desde un bundle obsoleto. Si la clave se pegó en un chat de IA, un tíquet de soporte o una captura, asume que se conservó y rótala. Por último, registra lo ocurrido, añade una comprobación que lo habría detectado y acorta la vida de la siguiente clave.

Usa esta secuencia antes de que un proyecto salga del navegador. Primero, clasifica cada valor: identificador público, credencial de usuario o secreto de servidor. Segundo, mantén los secretos de servidor fuera del bundle estático y colócalos detrás de una función serverless o una API. Tercero, expón solo los valores que necesitan el prefijo público e inspecciona los recursos compilados antes de desplegar. Cuarto, mantén los archivos .env fuera de Git, confirma un .env.example y activa el escaneo de secretos. Quinto, crea tokens con alcance y caducidad para GitHub y hosting, uno por propósito. Sexto, en GB Coder, deja las claves en memoria salvo que estés en un dispositivo de confianza, y opta por la persistencia de sesión solo cuando entiendas la contrapartida. Séptimo, nunca pegues una clave en un prompt, una incidencia, una captura o un archivo del proyecto. Octavo, rota ante cualquier duda y revoca antes de reemplazar. Noveno, usa un perfil de navegador limpio en máquinas compartidas. Décimo, escribe el plan para una filtración antes de necesitarlo. Un IDE de navegador puede gestionar credenciales de forma responsable si trata el navegador como un cliente público y no como una caja fuerte privada.