Cloudflare no es solo una plataforma de cómputo y almacenamiento: sus capacidades de seguridad son precisamente lo que la hizo famosa. Desde protección contra DDoS hasta firewalls inteligentes, pasando por rate limiting y CAPTCHAs modernos, la capa de seguridad complementa todo lo que ya se construyó en la plataforma de desarrollo.
¿Qué es el WAF y por qué es fundamental para proteger APIs?
El WAF (Web Application Firewall) es un producto dentro del dashboard de Cloudflare que permite agregar reglas de seguridad a nivel de aplicación [0:42]. Con él se pueden definir rate limits, controlar qué bots acceden al sitio o a las APIs, identificar patrones de tráfico malicioso e incluso activar protección contra DDoS.
Cloudflare es reconocido por reaccionar con velocidad ante amenazas. Cuando aparece un exploit de zero day, normalmente en el mismo día o al siguiente, la capa de firewall ya lo incluye y las aplicaciones proxyadas quedan protegidas [1:12]. Aun así, es recomendable parchar las aplicaciones y mantener las librerías actualizadas.
¿Por qué implementar rate limiting a nivel de Workers?
Aunque el rate limiting se puede activar directamente en el WAF, hacerlo a nivel de Workers ofrece mayor granularidad [1:35]. En el WAF solo se tiene acceso a headers y algunos datos del tráfico, pero en Workers se puede programar lógica personalizada: definir keys basados en propiedades específicas del usuario o de la petición.
¿Cómo se configura el binding de rate limit?
Al generar la configuración con ayuda de un LLM, surgieron errores que obligaron a consultar la documentación [2:38]:
- El key del binding no se escribe como texto plano, sino con una sintaxis específica.
- La propiedad correcta es
name, no binding.
- La duración mínima permitida es de 10 segundos y la máxima de 60 segundos.
Una vez corregidos estos valores y regenerados los tipos, los dos objetos de rate limit aparecieron correctamente en el entorno local [3:20].
¿Cómo funciona el rate limit en la práctica?
Al probar desde el front-end, se enviaron comentarios consecutivos. En el comentario número siete el sistema respondió con un código de estado 429 [4:28], indicando que se alcanzó el límite. La respuesta se generó directamente en el middleware, sin que el código de la ruta llegara a ejecutarse.
Hubo un detalle importante: los comentarios estaban almacenados en un Durable Object, no en la base de datos D1 directamente. Intentar consultar una tabla de comentarios en D1 generó un error SQL [3:52]. La solución fue eliminar la lógica de conteo y utilizar la propiedad lastComment del modelo ya existente en las migraciones.
¿Qué es Turnstile y cómo protege contra spam?
El rate limiting controla la cantidad de peticiones, pero no evita que lleguen correos basura o datos dummy. Para eso existe Turnstile [5:08], el equivalente de Cloudflare a reCAPTCHA de Google, pero con capacidades adicionales.
Turnstile ofrece dos modos principales:
- Modo invisible: el usuario no ve ningún reto.
- Modo challenge: se presenta una verificación visual.
El flujo funciona así: el widget en el front-end genera un token, y en el back-end se valida ese token contra un secret registrado en Cloudflare [5:45]. Para desarrollo local, es importante registrar localhost como dominio permitido, y tener una configuración separada para producción [7:02].
¿Cómo quedó la arquitectura final del proyecto?
El proyecto tiene dos aplicaciones: front-end y back-end [7:28].
- Back-end: incluye middlewares, tipos, rutas, un workflow y el Durable Object.
- Front-end: usa un modelo mixto donde el home funciona como SPA y otras páginas como stats y landing usan server render.
- El test A/B se implementó con KV y COPES.
Los bindings de Cloudflare en producción incluyen el Durable Object, los rate limits, la base de datos D1, el KV y un service binding que conecta el front-end con el back-end [8:20].
Un dato valioso: durante todo el curso se utilizó documentación contextual para que el LLM generara código más certero. Solo con el rate limit fue necesario corregir manualmente, lo que demuestra que siempre conviene verificar contra la documentación oficial [8:45].
Si llegaste hasta aquí, el reto es implementar Turnstile, documentar los endpoints faltantes con Swagger y compartir tu experiencia en los comentarios.
