Detección de fraude en el edge: Cloudflare Workers + tracio.ai
Ejecute la validación de la huella digital del dispositivo en Cloudflare Workers antes de que las solicitudes lleguen a su origen. Decisiones de fraude en menos de 5ms en el edge.
La detección de fraude tradicional ocurre en la capa de aplicación: la solicitud llega a su servidor, consulta su API de detección de fraude, espera la respuesta y luego decide si permitir o bloquear. Esta ida y vuelta añade 50-200ms de latencia a cada solicitud, algo aceptable para las cargas de página, pero doloroso para los endpoints de API, las llamadas AJAX y las interacciones en tiempo real.
¿Y si pudiera tomar la decisión de fraude antes de que la solicitud llegue a su servidor de origen? Eso es lo que habilita la computación en el edge, y Cloudflare Workers es la plataforma que usamos para demostrar este patrón.
La arquitectura
La configuración tiene tres componentes: el SDK de JS de tracio.ai (@tracio/sdk) ejecutándose en el navegador, un Cloudflare Worker situado entre el cliente y su origen, y webhooks firmados de tracio.ai que entregan el análisis completo de señales a su backend.
El flujo funciona así: el SDK de JS recopila señales del dispositivo y las envía a tracio.ai durante la carga de la página, devolviendo un visitorId al navegador. Su backend recibe el resultado completo de identificación —clasificación de bots, smart signals, confianza— a través de un webhook firmado y escribe el veredicto en una caché edge. El navegador incluye el visitorId en las solicitudes de API posteriores (mediante cabecera o cookie). El Cloudflare Worker intercepta cada solicitud, busca el veredicto en caché para ese visitorId y toma una decisión de permitir/bloquear en menos de 5ms.
Implementación del Worker
El Worker mantiene una caché ligera de los resultados recientes de verificación de dispositivos usando el almacenamiento KV de Cloudflare, poblada por su backend a medida que llegan los webhooks firmados de tracio.ai. Cuando llega una solicitud con una cabecera visitorId, el Worker comprueba la caché. Si el veredicto está en caché y el visitante está limpio (puntuación de bot baja, sin VPN, confianza por encima del umbral), la solicitud pasa de inmediato. Si aún no hay ningún veredicto en caché, el Worker aplica su política de reserva —dejar pasar con un límite de tasa conservador, o desafiar— hasta que la caché impulsada por el webhook se pone al día.
La observación clave es que la caché de verificación se puebla de forma proactiva. La primera carga de página dispara la recopilación de señales y guarda el resultado en caché. Todas las llamadas de API posteriores de ese visitante aciertan en la caché: no hace falta ninguna ida y vuelta a tracio.ai. El TTL de la caché es configurable; recomendamos 5 minutos para endpoints de alta seguridad y 30 minutos para contenido general.
Cifras de rendimiento
Hicimos un benchmark de esta arquitectura con un cliente que procesa 50,000 solicitudes por minuto a través de Cloudflare Workers. Resultados:
Tasa de aciertos de caché: 94% (la mayoría de las solicitudes provienen de visitantes que ya cargaron una página). Latencia de decisión en el edge (acierto de caché): 1.2ms de mediana, 3.8ms p99. Latencia de decisión en el edge (fallo de caché): 45ms de mediana (incluye la llamada a la API de tracio.ai). Ahorro de latencia de origen: 120ms de mediana por solicitud (comprobación antifraude del lado del servidor eliminada).
La tasa de aciertos de caché del 94% significa que el 94% de las decisiones de fraude ocurren en menos de 4ms en el edge, sin ninguna intervención del origen. El 6% restante son solicitudes de primera visita que requieren una ida y vuelta completa a la API.
Estrategias de bloqueo
El Worker admite tres estrategias de bloqueo, configurables por ruta:
Bloqueo duro: devolver un 403 de inmediato para visitantes de alto riesgo (puntuación de bot > 0.9, framework de automatización conocido). Bloqueo blando: añadir cabeceras X-Tracio-Risk y dejar que el origen decida. Esto es útil cuando quiere contexto a nivel de aplicación para la decisión. Desafío: redirigir a los visitantes sospechosos (puntuación de bot moderada, VPN detectada) a una página de desafío que requiere verificación adicional.
Recomendamos empezar con bloqueo blando en producción, monitorizar la distribución de riesgo durante una semana y luego habilitar el bloqueo duro para los casos claros (bots conocidos, navegadores headless, automatización de alta confianza).
Análisis de costes
Los precios de Cloudflare Workers se basan en las solicitudes y el tiempo de cómputo. A 50K solicitudes/minuto (2,16 mil millones al mes), el coste del Worker es de aproximadamente 500 $/mes. Compárelo con el ahorro de latencia: eliminar 120ms de comprobación antifraude del lado del origen reduce el uso de CPU del servidor en un 15-20%, lo que normalmente ahorra más que el coste del Worker en cómputo.
El valor real está en la prevención del fraude: atrapar bots y solicitudes fraudulentas antes de que consuman recursos de origen, conexiones a la base de datos y llamadas a APIs posteriores. Un cliente redujo su número de servidores de origen de 12 a 8 tras implementar la detección de fraude basada en el edge: los bots que consumían el 30% de su cómputo nunca llegaron al origen.