¿Puedo poner mi clave de API en el código de mi web?

Por qué una página no puede guardar un secreto

El navegador tiene que recibir todo lo que ejecuta. No es una carencia de un hosting o un framework concreto, es lo que significa servir una página: la máquina del visitante no puede ejecutar tu código sin que se le entregue tu código. Por eso las herramientas de desarrollo del propio navegador bastan para leer lo que haya ahí, sin conocimientos y sin instalar nada. Minificar, codificar en base64 o montar la clave a partir de fragmentos concatenados sobreviven exactamente el tiempo que tarda alguien en mirar el valor ya montado, que la pestaña de red le muestra igual, dentro de la petición que sale.

Así que la distinción que importa no es oculto frente a visible. Es entre dos tipos de credencial, y el proveedor te las nombra. Una clave publicable o de cliente está diseñada para vivir en una página: la clave publicable de una pasarela de pago, un identificador de medición de analítica, una clave de mapas restringida a tu dominio. Son públicas por diseño y están acotadas del lado del proveedor, y por eso ponerlas en el código de la web es correcto y no arriesgado. Una clave secreta es otra cosa por completo: normalmente lleva toda la autoridad de tu cuenta, así que puede cobrar tarjetas, leer registros de clientes, enviar correo en tu nombre o consumir tu presupuesto de API. Entregar eso a cualquiera que cargue la página es el error real, y "nadie conoce todavía esta dirección" no es una defensa, porque hay escáneres rastreando webs recién publicadas y repositorios públicos de forma continua buscando precisamente esto.

Si ya está en vivo, rota antes de ordenar

El impulso es borrar la línea y volver a publicar. Haz primero la otra cosa. Despublicar no recupera lo que ya se sirvió: la versión antigua puede quedarse en la caché de una CDN, en la caché de un buscador, en un servicio de archivo o en el navegador de un visitante, y si la página vive en un repositorio la clave permanece en el historial de commits, donde quitar la línea en un commit posterior deja el anterior perfectamente legible. El único paso que de verdad termina la exposición es invalidar la credencial en el proveedor, porque el proveedor es el único sitio donde la clave tiene que comprobarse.

Dónde va la clave en su lugar, y qué encontramos en páginas en vivo

El patrón que funciona es que la página no guarde nunca el secreto. La página llama a algo que tú controlas, eso guarda la clave y hace la llamada de salida, y el navegador del visitante solo habla contigo. A menudo no tienes que montarlo tú: el widget alojado de un proveedor o un servicio de backend gestionado hacen de servidor a estos efectos. Si necesitas algo más es otra pregunta, y mi web necesita un backend explica dónde está realmente la línea.

Operar nuestro propio alojamiento nos enseñó algo contraintuitivo sobre esto. AgentCeres — el AI Growth Officer de agentceres.com — aloja las páginas que sus agentes construyen para los clientes, y cada una de esas páginas se sirve con una política de seguridad de contenido que impide a la página hacer cualquier petición de red. Una clave incrustada en una página así no puede ni usarse desde ella: el código puede ejecutarse, calcular y navegar, y no tiene a dónde enviar nada. Esa contención protege al visitante de la página, y no hace absolutamente nada por esconder la clave del visitante — que es la mitad que la gente da por supuesta.

El 2026-09-17 repasamos las páginas que los clientes habían publicado y encontramos una cuyo JavaScript asignaba a una variable la clave secreta real de una pasarela de pago, con el número de documento de identidad de un cliente escrito a mano en una función de consulta más abajo en el mismo archivo. Ambas cosas se confirmaron descargando la página en vivo, no se dedujeron. No había pasado nada exótico: el propietario pegó la clave en un chat mientras pedía una funcionalidad que la necesitaba, y se escribió en la página. La regla que salió de ahí es la que conviene llevarse — nunca pegues un secreto real en un chat con algo que escribe tu página, incluido un asistente de código, porque lo natural para él es usar la clave donde está el código.

La misma revisión encontró la fuga en el sentido contrario, que conviene conocer porque casi nadie lo comprueba. Las páginas generadas incluyen formularios de acceso y de registro cuando alguien pide un área de miembros, incluso donde no existe servidor detrás que autentique a nadie, y todos los formularios de esa página acaban conectados a un gestor de formularios — así que un visitante que escribía una contraseña ahí la veía almacenada y reenviada en texto plano. En dos casos de septiembre de 2026 eso incluyó el correo y la contraseña reales de un tercero, llegando a la bandeja del propietario con el aspecto de una consulta cualquiera. Ahora reconocemos nombres de campo con forma de credencial y eliminamos esos valores antes de que se almacene, se envíe o se muestre nada, y las páginas recién publicadas dejan ese campo sin posibilidad de envío desde el principio. La lección general se sostiene sea quien sea quien construyó la página: puede filtrar en las dos direcciones, tus claves hacia fuera y las contraseñas de tus visitantes hacia dentro.