Componer defensas: Turnstile, rate limit y Access en capas

Las tres piezas de este nivel se confunden con facilidad porque las tres terminan devolviendo un rechazo, y visto desde el error un 403 se parece mucho a otro. Pero responden a preguntas que no se solapan en absoluto: Turnstile pregunta si al otro lado hay un navegador gobernado por una persona, el límite de tasa pregunta si alguien va demasiado rápido, y Access pregunta quién eres antes siquiera de dejarte llamar a la puerta. Ninguna sustituye a las otras, y usar una donde tocaba otra produce sistemas que se sienten seguros y no lo están. La ingeniería del nivel no está en elegir: está en ordenarlas.

Tres preguntas que no se solapan

La tabla se lee mal si se interpreta como un menú del que se elige una fila. Se lee bien como cuatro filtros con radios distintos: uno descarta lo evidente, otro contiene el volumen, otro separa personas de programas y el último separa a los conocidos de todos los demás. Un formulario público necesita los tres primeros y no puede usar el cuarto, porque exigir identidad a quien viene a contactarte contigo es cerrar la puerta que querías abrir. Un panel interno necesita el cuarto y casi puede prescindir de los otros.

Hay además una asimetría temporal entre ellas que conviene tener en la cabeza. Access decide una vez y su decisión dura toda una sesión, así que su coste se amortiza. Turnstile decide una vez por envío y su veredicto caduca en minutos. El límite de tasa no decide nunca del todo: reevalúa en cada petición porque su objeto de estudio es precisamente el ritmo, algo que no existe en un instante aislado. Preguntas con horizontes distintos exigen mecanismos distintos, y ese es el motivo profundo de que ninguna pueda absorber a las otras.

El orden importa: de lo barato a lo caro

Este es el principio operativo del nivel y se enuncia en una línea: rechaza lo antes posible, con la comprobación más barata que sea capaz de rechazarlo. Ponerlo del revés, verificar Turnstile con su subpetición antes de mirar un límite de tasa que se resuelve en memoria, significa que cada petición de una ráfaga te cuesta una llamada externa. El atacante ha logrado que pagues por rechazarlo.

flowchart TD
P[peticion entrante] --> W[WAF de zona]
W --> RL[limite de tasa por clave]
RL --> ID{hay identidad}
ID -->|si| AC[verificar token de Access]
ID -->|no| TS[verificar token de Turnstile]
AC --> L[logica y escrituras]
TS --> L
RL -.rechazo 429.-> F[respuesta barata]
TS -.rechazo 403.-> F
style RL fill:#89b4fa,color:#11111b
style L fill:#a6e3a1,color:#11111b

export default {
  async fetch(request, env, ctx): Promise<Response> {
    const ip = request.headers.get("CF-Connecting-IP") ?? "sin-ip";

    // 1. barato y local: contiene el volumen antes de gastar nada
    const tasa = await env.LIMITE_FORM.limit({ key: `form:${ip}` });
    if (!tasa.success) {
      return new Response("Demasiados envios", {
        status: 429,
        headers: { "Retry-After": "60" },
      });
    }

    // 2. una subpeticion: solo para quien ya paso el filtro anterior
    const form = await request.formData();
    const veredicto = await verificarTurnstile(env, form, ip);
    if (!veredicto.success || veredicto.action !== "contacto") {
      return new Response("Verificacion fallida", { status: 403 });
    }

    // 3. lo caro: escrituras, correo, inferencia
    ctx.waitUntil(env.COLA_CONTACTO.send(Object.fromEntries(form)));
    return new Response("Recibido", { status: 202 });
  },
} satisfies ExportedHandler<Env>;

Dos casos resueltos

El formulario público de contacto es el caso canónico y ya está arriba: límite de tasa por IP y por operación, Turnstile con su action comprobada, y el trabajo caro desplazado a una cola. Nada de identidad, porque el visitante no tiene ninguna y exigírsela contradice el propósito del formulario.

El endpoint interno es la imagen especular. Aquí Access va delante de todo y filtra en la frontera: quien no tenga una identidad válida de tu proveedor no llega ni a ejecutar tu Worker. Lo que sí debe hacer tu código es verificar el token que Access inyecta, en lugar de dar por hecho que la puerta hizo su trabajo.

async function identidadDeAccess(request: Request, env: Env) {
  const jwt = request.headers.get("Cf-Access-Jwt-Assertion");
  if (!jwt) return null;

  // las claves publicas del equipo viven en el endpoint de certificados
  const claves = await obtenerClaves(env.ACCESS_TEAM_DOMAIN);
  const payload = await verificarJwt(jwt, claves, env.ACCESS_AUD);
  return payload ? { correo: payload.email, sujeto: payload.sub } : null;
}

Hay un tercer caso intermedio que conviene nombrar porque se resuelve mal con frecuencia: el endpoint que consume otra máquina. No hay navegador, así que Turnstile es imposible por definición y forzarlo solo produce integraciones rotas. Tampoco hay persona a la que enviar a un proveedor de identidad. Lo que encaja son los tokens de servicio de Access, un par de credenciales que el cliente presenta en cabeceras y que la frontera valida antes de tu código, combinados con un límite de tasa por identidad de cliente y no por dirección de red, porque un integrador serio saldrá desde direcciones que cambian.

Fallar bien

Queda la parte que casi nadie escribe y que decide si la composición sirve. Toda defensa probabilística produce falsos positivos, así que la pregunta no es si rechazarás a un cliente legítimo sino qué le ocurrirá cuando pase. Si su formulario se vacía, si el mensaje de error es un 403 desnudo o si no hay forma de reintentar, tu defensa está causando más pérdida que el abuso que evitaba.

La forma madura de reducir ese coste no es aflojar los números, es escalonar la exigencia. El primer envío de un visitante puede pasar sin ninguna fricción visible; el tercero en un minuto ya justifica una comprobación con widget; el décimo merece una espera explícita. La señal que dispara cada escalón la tienes ya, porque es el propio contador de tasa: en lugar de usarlo solo para rechazar, úsalo para decidir cuánta prueba pedir.

const suave = await env.LIMITE_SUAVE.limit({ key: `form:${ip}` });
const duro = await env.LIMITE_DURO.limit({ key: `form:${ip}` });

if (!duro.success) return respuesta429();
const exigirPrueba = !suave.success; // solo a partir del segundo escalon

Y queda la pregunta gemela: qué haces cuando la propia defensa no está disponible. Si el servicio de validación de Turnstile no responde, ¿rechazas a todo el mundo o dejas pasar sin comprobar? Ninguna respuesta es universalmente correcta, y esa es exactamente la razón por la que debe ser una decisión consciente y anotada, distinta para el formulario de contacto que para el endpoint que mueve dinero. Lo inaceptable no es elegir mal: es no haber elegido y descubrir tu política de fallo en producción.