¿API Key expuesta en el frontend y con riesgo de abuso? Proxy con Workers en 5 minutos: protege tus claves con 100.000 solicitudes gratis al día

Hice una herramienta pequeña que llamaba a la API de ChatGPT y dejé la API Key directamente en el código del frontend. Al día siguiente, mi cuenta fue abusada por más de 300 yuanes: miles de llamadas en una sola noche. Las variables de entorno tampoco sirven; las de Vite o Webpack acaban empaquetadas en el archivo JS, y cualquiera puede ver las solicitudes completas en el panel Network.

La solución tradicional es montar un servidor backend como proxy, pero eso cuesta dinero y además implica configurar el entorno, certificados SSL y CORS. Cloudflare Workers despliega un proxy API en 5 minutos, con la API Key en variables de entorno del servidor, fuera del alcance del frontend. Es totalmente gratis, con 100.000 solicitudes al día. Este artículo te enseña cómo montarlo.

Por qué la API Key no puede ir en el frontend

El código del frontend es totalmente transparente

Mucha gente cree que usar un archivo .env o import.meta.env de Vite ya es seguro. En realidad, eso solo es una comodidad en desarrollo: tras el build, todas las variables de entorno quedan hardcodeadas en el archivo JS.

No me creas: abre cualquier proyecto frontend en producción, pulsa F12, ve al panel Network y recarga la página. Verás todas las solicitudes API, incluidos headers, body y parámetros de URL, completamente expuestos.

Aunque uses ofuscación o minificación, solo haces el código más difícil de leer. La llamada API tiene que enviar la Key real, y eso no se puede ofuscar. ¿Encriptar? El problema es que el código de cifrado y descifrado también está en el frontend; el usuario puede verlo igual.

En pocas palabras: el frontend se ejecuta en el navegador del usuario. Todo lo que tú puedes hacer, el usuario también. No hay solución.

Cuánto cuesta que te roben la Key

Antes pensaba: ¿quién va a aburrirse revisando mi código para robar la API Key? Después supe que en internet hay gente dedicada a eso.

En GitHub hay herramientas que escanean proyectos automáticamente buscando API Keys expuestas. Cuando las encuentran, alguien las usa para abusar de la API: o para aprovecharse gratis, o para revenderlas. La API de OpenAI cobra por token; que te roben la Key una noche y gastes cientos de yuanes es normal; en casos graves, miles.

Vi una discusión en un foro de desarrolladores: alguien hizo una página de chat con IA y dejó la Key en el frontend. La encontraron y la llamaron sin parar; la factura del mes se disparó a más de 2000 dólares. Aunque luego logró una reclamación, el proceso fue un dolor de cabeza.

Y no es solo OpenAI: Google Maps API, APIs del tiempo, APIs de traducción… cualquier servicio de pago por uso tiene riesgo de abuso.

Los problemas de la solución tradicional

Cuando entendí el riesgo, empecé a investigar cómo resolverlo. Casi todas las soluciones en internet dicen lo mismo: «monta un servidor backend como proxy».

Suena simple, pero en la práctica:

• Costo: el servidor en la nube más barato (instancias ligeras de Alibaba Cloud, Tencent Cloud, etc.) cuesta entre 50 y 100 yuanes al mes. No es una fortuna, pero para un proyecto personal pequeño, duele.
• Configuración compleja: instalar Node.js u otro runtime, configurar Nginx como proxy inverso, pedir certificados SSL para HTTPS, resolver CORS… Solo entender todo eso puede llevar medio día.
• Mantenimiento: el servidor hay que actualizarlo, monitorizarlo y reiniciarlo si se cae. Un proyecto pequeño no aguanta tanto lío.

Las funciones serverless de los grandes proveedores chinos (Alibaba Function Compute, Tencent Cloud Functions) ahorran dinero, pero la configuración es más compleja, el cold start es lento y la documentación no ayuda mucho. Lo intenté varias veces sin éxito.

La API Gateway suena profesional, pero son productos de nivel empresarial; para un desarrollador individual, la barrera es demasiado alta.

Ventajas de la solución con Cloudflare Workers

Totalmente gratis y con buen rendimiento

La cuota gratuita de Cloudflare Workers es de 100.000 solicitudes al día. Para un proyecto personal, sobra. Mi herramienta pequeña hace unas pocas centenas de llamadas al día; la cuota gratuita me basta de sobra.

Además, Cloudflare tiene más de 200 centros de datos en el mundo; tu código se despliega automáticamente en esos nodos. Cuando un usuario accede, el tráfico se enruta al nodo más cercano y la respuesta es muy rápida. A diferencia de un servidor tradicional, si lo compras en una región, el resto del mundo accede más lento.

Otro punto importante: Workers no tiene cold start. Las funciones serverless (como AWS Lambda) pueden tardar varios segundos en arrancar si llevan tiempo sin solicitudes. Workers responde en milisegundos; la experiencia se parece a un servidor tradicional.

Despliegue extremadamente simple

La primera vez que usé Workers, desde registrarme hasta desplegar, tardé literalmente 5 minutos. Sin exagerar.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

No hace falta configurar un servidor, instalar Node.js o Nginx, ni pedir certificados SSL (Workers te da HTTPS automáticamente). Solo tienes que:

1. Escribir el código (un archivo JS, unas decenas de líneas)
2. Ejecutar un comando: wrangler publish
3. Listo

Tras el despliegue, Cloudflare te da un dominio como your-worker.your-subdomain.workers.dev, listo para usar. Si quieres tu propio dominio, lo vinculas en la consola; no hace falta configuración extra.

Compara con la solución tradicional: comprar servidor → configurar entorno → escribir código → configurar Nginx → pedir certificado → desplegar → probar… Solo leer el flujo ya cansa.

Resuelve CORS de forma natural

Llamar APIs de terceros desde el frontend suele chocar con errores CORS, por ejemplo: Access to fetch at 'xxx' from origin 'yyy' has been blocked by CORS policy.

Es una restricción de seguridad del navegador: las solicitudes entre dominios distintos se bloquean. La solución tradicional es que el proveedor de la API añada headers CORS, pero tú no puedes cambiar la configuración de una API de terceros.

Con Workers como proxy queda resuelto:

• El frontend llama a tu propia URL de Workers (por ejemplo https://api.yourdomain.com)
• Workers llama a la API de terceros
• Workers devuelve la respuesta añadiendo headers CORS

Para el navegador, llamas a un endpoint del mismo origen; no hay CORS. Para la API de terceros, quien llama es el servidor de Workers; tampoco hay CORS.

Cuando llamaba a la API de mapas de Amap, siempre me salía error CORS. Con el proxy de Workers, dos líneas de código y listo.

Práctica: monta tu primer proxy API

Bien, tras tantas ventajas, vamos paso a paso. Usaré la API de OpenAI como ejemplo; el método es parecido para otras APIs.

Paso 1: preparar el entorno

1. Registra una cuenta en Cloudflare

Ve a cloudflare.com y regístrate; el plan gratuito basta. El proceso es simple: verifica el correo y listo.

2. Instala Wrangler CLI

Wrangler es la herramienta de línea de comandos oficial de Cloudflare para crear y desplegar Workers.

npm install -g wrangler

Si no tienes Node.js, descárgalo e instálalo desde nodejs.org.

3. Inicia sesión y autoriza

wrangler login

Este comando abre el navegador para autorizar. Acepta y la CLI podrá gestionar tus Workers.

Paso 2: crear el proyecto Worker

wrangler init openai-proxy

El comando te hará algunas preguntas:

• “Would you like to use TypeScript?” → elige No (salvo que domines TS)
• “Would you like to create a new Worker?” → elige Yes
• “Would you like to install dependencies?” → elige Yes

Al terminar, tendrás una carpeta de proyecto con esta estructura aproximada:

openai-proxy/
├── src/
│   └── index.js       # Aquí va tu código
├── wrangler.toml      # Archivo de configuración
└── package.json

Paso 3: escribir el código del proxy

Abre src/index.js, borra el código por defecto y sustitúyelo por esto:

export default {
  async fetch(request, env) {
    // Solo permitir solicitudes POST
    if (request.method !== 'POST') {
      return new Response('Method not allowed', { status: 405 });
    }
    // Leer la API Key de OpenAI desde variables de entorno
    const apiKey = env.OPENAI_API_KEY;
    if (!apiKey) {
      return new Response('API Key not configured', { status: 500 });
    }
    try {
      // Obtener el body enviado desde el frontend
      const body = await request.json();
      // Llamar a la API real de OpenAI
      const response = await fetch('https://api.openai.com/v1/chat/completions', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Authorization': `Bearer ${apiKey}`,  // Key del servidor
        },
        body: JSON.stringify(body),
      });
      // Obtener datos de la respuesta
      const data = await response.json();
      // Devolver al frontend y añadir headers CORS
      return new Response(JSON.stringify(data), {
        status: response.status,
        headers: {
          'Content-Type': 'application/json',
          'Access-Control-Allow-Origin': '*',  // Permitir acceso desde cualquier dominio
          'Access-Control-Allow-Methods': 'POST',
          'Access-Control-Allow-Headers': 'Content-Type',
        },
      });
    } catch (error) {
      return new Response(JSON.stringify({ error: error.message }), {
        status: 500,
        headers: { 'Content-Type': 'application/json' },
      });
    }
  },
};

El código es sencillo:

1. Recibe solicitudes POST del frontend
2. Lee la API Key real desde variables de entorno (el frontend nunca la ve)
3. Usa esa Key para llamar a la API de OpenAI
4. Devuelve el resultado al frontend y añade headers CORS para evitar problemas de origen cruzado

Paso 4: configurar Secrets (almacenar la API Key)

Este es el paso más importante. La API Key no puede ir en el código; hay que guardarla con Secrets de Cloudflare, cifrada.

Ejecuta:

wrangler secret put OPENAI_API_KEY

Te pedirá el valor de la Key. Pega tu API Key de OpenAI y pulsa Enter.

La Key se guarda cifrada en los servidores de Cloudflare; ni siquiera en la consola se ve en texto plano. En el código la lees con env.OPENAI_API_KEY.

¿Y en desarrollo local?

Crea un archivo .dev.vars en la raíz del proyecto:

OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx

Solo se usa en desarrollo local; no lo subas a Git. Añade esta línea a .gitignore:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

.dev.vars

Paso 5: probar en local

En el directorio del proyecto, ejecuta:

wrangler dev

Esto levanta un servidor local, por defecto en http://localhost:8787. Puedes probar con Postman o desde el frontend:

fetch('http://localhost:8787', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'gpt-3.5-turbo',
    messages: [{ role: 'user', content: 'Hello!' }],
  }),
})
  .then(res => res.json())
  .then(data => console.log(data));

Si recibes la respuesta de OpenAI con normalidad, el proxy funciona.

Paso 6: desplegar a producción

Cuando las pruebas estén bien, un solo comando:

wrangler publish

Tarda unos segundos. Tras el despliegue, Cloudflare te da una URL como:

https://openai-proxy.your-subdomain.workers.dev

Cambia en el frontend la URL de la API por esta y listo. La API Key no quedará expuesta en el cliente.

Si quieres tu propio dominio, en la consola de Cloudflare ve a Workers → tu Worker → Settings → Triggers → Add Custom Domain, introduce tu dominio (por ejemplo api.yourdomain.com) y configura DNS según las indicaciones.

Técnicas avanzadas y buenas prácticas

El código anterior ya funciona, pero hay margen de mejora. Comparto algunas técnicas avanzadas.

Evitar que abusen de tu proxy

Ahora tu Worker es público: quien conozca la URL puede llamarlo. Si alguien abusa, puedes agotar la cuota gratuita rápido; en casos graves, incluso generar costos.

Validación simple con token

Puedes añadir un mecanismo de verificación:

export default {
  async fetch(request, env) {
    // Validar el token del header de la solicitud
    const token = request.headers.get('X-API-Token');
    if (token !== env.MY_SECRET_TOKEN) {
      return new Response('Unauthorized', { status: 401 });
    }
    // ... lógica del proxy a continuación
  },
};

Luego configura un secreto con wrangler secret put MY_SECRET_TOKEN. El frontend envía el token en la solicitud:

fetch('https://your-worker.workers.dev', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Token': 'your-secret-token',  // Este token también puede ir en variables de entorno del frontend
  },
  body: JSON.stringify(data),
});

Aunque el token sigue visible en el frontend, al menos añades una barrera. Puedes rotarlo periódicamente o asignar tokens distintos por usuario.

Lista blanca de IP

Si la app solo se usa en dominios concretos, puedes restringir el origen:

const allowedOrigins = ['https://yourdomain.com', 'http://localhost:3000'];
const origin = request.headers.get('Origin');
if (!allowedOrigins.includes(origin)) {
  return new Response('Forbidden', { status: 403 });
}

Soportar varias APIs

Si necesitas proxy para varias APIs, puedes distinguirlas por ruta:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    // Reenviar a distintas APIs según la ruta
    if (url.pathname.startsWith('/openai')) {
      return proxyOpenAI(request, env);
    } else if (url.pathname.startsWith('/maps')) {
      return proxyMaps(request, env);
    } else {
      return new Response('Not found', { status: 404 });
    }
  },
};
async function proxyOpenAI(request, env) {
  // Lógica del proxy de OpenAI
}
async function proxyMaps(request, env) {
  // Lógica del proxy de la API de mapas
}

Así un solo Worker puede atender varias APIs.

Gestionar solicitudes OPTIONS (CORS completo)

El código anterior solo maneja POST. Antes de una solicitud cross-origin, el navegador envía una preflight OPTIONS. Un CORS completo sería así:

export default {
  async fetch(request, env) {
    // Gestionar solicitud preflight CORS
    if (request.method === 'OPTIONS') {
      return new Response(null, {
        headers: {
          'Access-Control-Allow-Origin': '*',
          'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
          'Access-Control-Allow-Headers': 'Content-Type, X-API-Token',
          'Access-Control-Max-Age': '86400',
        },
      });
    }
    // ... procesamiento normal de la solicitud
  },
};

Monitorización y depuración

En la consola de Cloudflare puedes ver el estado del Worker:

• Número de solicitudes
• Tasa de errores
• Tiempo de respuesta

Para ver logs en tiempo real, usa wrangler tail:

wrangler tail

Muestra los logs de todas las solicitudes y facilita la depuración. Lo que imprimas con console.log() también aparece.

Preguntas frecuentes

¿Qué pasa si se agota la cuota gratuita?

100.000 solicitudes al día bastan de sobra para proyectos personales. En mis propios proyectos llevo meses sin superar la cuota gratuita.

Si de verdad no alcanza, el plan de pago de Workers no es caro: 5 dólares al mes por 10 millones de solicitudes. Frente a comprar un servidor, el precio es razonable.

¿Workers es estable? ¿Puede caerse de repente?

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Cloudflare es uno de los mayores proveedores de CDN del mundo; la infraestructura es muy fiable. Llevo más de medio año usándolo sin indisponibilidad.

Oficialmente garantizan un SLA del 99,99 %; la probabilidad de fallo es menor que con un servidor propio.

¿Puedo usar mi propio dominio?

Sí. Vincula un dominio personalizado en la consola de Cloudflare y configura DNS. El proceso lleva unos 5 minutos; no hace falta configurar certificados (HTTPS automático).

¿Cómo es la velocidad desde China?

Cloudflare tiene nodos en China; la velocidad es aceptable. En mis pruebas, la latencia suele estar entre 100 y 300 ms, mucho más rápido que llamar directamente a APIs en el extranjero.

No iguala a servicios optimizados solo para China. Si la velocidad es crítica, puedes valorar plataformas serverless locales (como Alibaba Function Compute), aunque la configuración es más compleja.

¿Admite otros lenguajes además de JavaScript?

Workers admite principalmente JavaScript y TypeScript. Si prefieres otro lenguaje, puedes compilar a WebAssembly, pero la barrera es más alta.

Para un proxy API sencillo, JavaScript basta.

¿Es realmente seguro?

Mientras no devuelvas la API Key al frontend en la respuesta, es seguro. Los Secrets se almacenan cifrados; ni en la consola se ven en texto plano.

Aun así, conviene controlar el acceso para evitar abuso del proxy. La validación por token y la lista blanca de orígenes ayudan.

Conclusión

La fuga de API Keys me preocupó bastante tiempo. Al principio pensé que no había buena salida: o asumir el riesgo, o pagar un servidor.

Hasta que descubrí Cloudflare Workers y vi que podía ser tan simple: despliegue en 5 minutos, gratis, Key segura en el servidor, CORS resuelto de paso. Juntas, esas ventajas hacen de Workers una opción casi perfecta para proyectos personales.

Si también haces proyectos que llaman APIs de terceros, te recomiendo probar este método. No es difícil: sigue los pasos de arriba y en media hora lo tienes.

El código está detallado; puedes copiarlo y adaptarlo. Si tienes dudas, consulta la documentación oficial de Cloudflare o deja un comentario; te responderé cuando lo vea.

Un aviso final: tras desplegar, configura controles de acceso para que no abusen de tu proxy. Añadir validación por token o restringir el dominio de origen son medidas simples y efectivas.

¡Regístrate en Cloudflare y pruébalo ya!