Evidencia y registros de Cloudflare Bot Score

Cloudflare Bot Score es una señal por solicitud, no una prueba de identidad transparente. Cloudflare publica una escala de 1 a 99 y varias variables, pero las entradas y ponderaciones de una decisión no forman una explicación pública campo por campo. Este artículo basado en fuentes no informa de ninguna ejecución de BotBrowser ni de una zona de Cloudflare.

TL;DR

• Cloudflare documenta BotScore de 1 a 99. Una puntuación baja indica que considera más probable la automatización y una alta que considera más probable una solicitud humana; ninguna es un veredicto sobre una persona.
• El valor documentado 0 significa que Bot Management no evaluó la solicitud; no significa que sea segura o humana.
• cf.bot_management.score, BotScoreSrc y BotTags son campos documentados de solicitud o evento. Su disponibilidad depende del producto, plan, conjunto de datos y contexto del registro.
• Una acción challenge es un resultado de flujo de seguridad. Un estado HTTP es un resultado de respuesta. Conserva ambos junto a la puntuación sin tratarlos como la causa ni la identidad del solicitante.
• Registra solo los campos necesarios para una decisión acotada de soporte o lanzamiento. No infieras pesos privados, recojas una huella de una persona ni afirmes que un desafío demuestra que alguien lo superó.

Contenido

• Leer los campos públicos
• Crear un registro acotado
• Separar puntuación, desafío y resultado HTTP
• Declarar los límites
• Conclusión práctica

Leer los campos públicos

La referencia de Bot Score de Cloudflare define una escala de 1 a 99. Sus ejemplos dicen que 1 significa que Cloudflare considera bastante cierto que la solicitud fue automatizada y 99 que considera bastante cierto que provino de una persona. Es una evaluación de probabilidad para una solicitud, no identifica a una persona, no revela una explicación completa del modelo ni establece intención.

La página de variables de Bot Management nombra variables como cf.bot_management.score, cf.bot_management.verified_bot y cf.bot_management.static_resource. verified_bot identifica un bot permitido por Cloudflare, no una persona verificada; static_resource describe una clase configurada de recurso, no quién inició la solicitud. El conjunto HTTP requests de Logpush incluye campos como BotScore, BotScoreSrc y BotTags. Un nombre de campo no garantiza que toda zona, plan, evento o fila histórica tenga un valor. Registra el conjunto de datos y el estado de disponibilidad junto al campo.

BotScoreSrc aporta metadatos públicos de origen cuando el conjunto los entrega, pero no revela todas las entradas del detector. La documentación de motores de detección de bots describe categorías de motores a nivel público, no una tabla completa de pesos que permita reconstruir una puntuación a partir de propiedades del navegador. Por eso una revisión debe citar la definición pública, no inventar una explicación de ponderación. Para separar compatibilidad de perfil personal, consulta grupos de señales y límites de observación y la guía de evidencia de ejecución V8Log.

Crear un registro acotado

Usa un identificador estable de solicitud y conserva solo las entradas sobre las que un propietario pueda actuar. Conserva URL de origen y revisión del esquema para distinguir después un campo ausente de un conjunto cambiado. Esta es una plantilla documental, no una salida observada de Cloudflare:

{
  "recordType": "cloudflare-bot-evidence",
  "schema": "public-fields-only-v1",
  "requestId": "redacted-request-01",
  "testedOn": "2026-10-29",
  "dataset": "zone/http_requests",
  "fields": {
    "BotScore": null,
    "BotScoreSrc": null,
    "BotTags": [],
    "challengeAction": "not-recorded",
    "httpStatus": null
  },
  "availability": "source-based-fixture",
  "interpretation": "No runtime result; consult the cited field documentation."
}

Los valores null y la etiqueta source-based-fixture son deliberados: impiden confundir la plantilla con una exportación de zona. En un registro autorizado, reemplázalos por valores devueltos, conserva los nombres exactos y redacta URL, cookies, cuerpos, identificadores de cuenta y cabeceras completas salvo necesidad documentada. Si un campo falta, distingue not-enabled, not-in-dataset, null y not-requested; cada estado responde a una pregunta operativa distinta. La guía de fingerprinting de W3C explica por qué unir señales aumenta la exposición de privacidad.

Separar puntuación, desafío y resultado HTTP

Usa esta tabla al recibir varios registros. La regla es asignar cada observación a su capa antes de preguntar qué cambió.

Observación	Puede respaldar	No puede establecer	Siguiente comprobación
BotScore 1-99	La señal de probabilidad documentada para esa solicitud	Identidad, pesos, intención ni un veredicto universal de bot	Confirma plan, conjunto de datos, hora y BotScoreSrc
BotScoreSrc o BotTags	Metadatos públicos de origen o etiquetas si aparecen	El rastro completo del detector ni la razón de cada etiqueta	Lee la variable correspondiente y la versión del esquema Logpush
Acción challenge	Que se seleccionó o expuso un flujo de seguridad	Que el solicitante fuera malicioso, humano o verificado con éxito	Registra por separado resultado y política de la aplicación
Estado HTTP 200, 403 u otro	El resultado de respuesta observado por cliente o registro	Por qué ocurrió, quién lo inició o si una persona superó un desafío	Une hora, ruta y acción con un identificador controlado por el propietario

Las filas no son transitivas. Una puntuación alta seguida de 403 no demuestra que una persona fue bloqueada. Una baja seguida de 200 no demuestra que se aceptó automatización. Un desafío seguido de 200 tampoco demuestra que alguien lo resolvió. Conserva la secuencia y el propietario de cada registro.

Declarar los límites

La documentación pública permite hablar del significado y alcance de campos nombrados, no de pesos ocultos, del vector completo de entradas ni de la identidad de quien solicita. El glosario de fingerprinting de MDN describe la combinación de datos del navegador y dispositivo para distinguir usuarios o dispositivos; por eso un registro de puntuación no debe convertirse en una huella entre contextos.

Mantén score, challengeAction y httpStatus como columnas separadas. Escribe primero el hecho acotado: “el registro contenía una puntuación X en el conjunto Y a la hora Z”. Después la acción: “la aplicación devolvió Q tras R”. Evita decir que Cloudflare “sabía” que era un bot o que alguien probó ser humano. BotBrowser no expone entradas o pesos privados, no fuerza desafíos ni convierte un estado HTTP en identidad. Revisa las fuentes cuando cambie el esquema o la disponibilidad.

BotBrowser puede automatizar un flujo autorizado y observar el estado visible de la página, como describe su documentación de consistencia de automatización; no puede leer una zona de Cloudflare ni producir BotScore, BotScoreSrc y BotTags, que deben proceder del producto y conjunto de datos configurados en Cloudflare.

Fuentes

• Cloudflare Bot scores
• Cloudflare Bot Management variables
• Cloudflare HTTP requests Logpush fields
• Cloudflare bot detection engines
• W3C Fingerprinting Guidance
• MDN Fingerprinting glossary

Conclusión práctica

Usa Bot Score y sus campos públicos como evidencia de solicitud con alcance definido. Separa acciones de desafío y resultados HTTP, documenta disponibilidad y tiempo, y detente antes de inferir pesos, identidad o intención humana cierta. Verifica el conjunto y plan exactos en las referencias actuales de Cloudflare antes de añadir un campo a un esquema de soporte.