Preuves et journaux Cloudflare Bot Score

Cloudflare Bot Score est un signal au niveau d’une requête, pas un test d’identité transparent. Cloudflare publie une échelle de 1 à 99 et plusieurs variables, mais les entrées et pondérations d’une décision ne constituent pas une explication publique champ par champ. Cet article fondé sur les sources ne rapporte aucun essai BotBrowser ou aucune exécution de zone Cloudflare.

TL;DR

• Cloudflare documente BotScore de 1 à 99. Un score bas signifie que l’automatisation est jugée plus probable et un score haut qu’une requête humaine est jugée plus probable ; aucun n’est un verdict sur une personne.
• La valeur documentée 0 signifie que Bot Management n’a pas évalué la requête ; elle ne signifie ni sûre ni humaine.
• cf.bot_management.score, BotScoreSrc et BotTags sont des champs documentés de requête ou d’événement. Leur disponibilité dépend du produit, du plan, du jeu de données et du contexte.
• Une action challenge est un résultat de workflow de sécurité. Un statut HTTP est un résultat de réponse. Conservez-les avec le score sans les traiter comme la cause ou l’identité du demandeur.
• Journalisez seulement les champs nécessaires à une décision de support ou de mise en production bornée. N’inférez pas les poids privés, ne construisez pas une empreinte d’une personne et ne dites pas qu’un défi prouve qu’une personne l’a réussi.

Sommaire

• Lire les champs publics
• Construire une preuve bornée
• Séparer score, défi et résultat HTTP
• Décrire les limites d’inférence
• Conclusion pratique

Lire les champs publics

La référence Bot Score de Cloudflare définit une échelle de 1 à 99. Ses exemples indiquent que 1 signifie que Cloudflare est très certain que la requête était automatisée et 99 qu’elle venait d’un humain. Cela décrit une probabilité pour une requête ; cela n’identifie pas une personne, ne révèle pas l’explication complète du modèle et n’établit pas l’intention.

La page des variables Bot Management nomme notamment cf.bot_management.score, cf.bot_management.verified_bot et cf.bot_management.static_resource. verified_bot indique un bot autorisé par Cloudflare, pas une personne vérifiée ; static_resource décrit une classe de ressource configurée, pas l’initiateur de la requête. Le jeu de données Logpush HTTP requests liste notamment BotScore, BotScoreSrc et BotTags. Un nom de champ ne garantit pas qu’une zone, un plan, un événement ou une ligne historique contienne une valeur. Enregistrez le jeu de données et l’état de disponibilité avec le champ.

BotScoreSrc fournit des métadonnées publiques de source lorsqu’elles existent, mais ne révèle pas toutes les entrées du détecteur. La documentation des moteurs de détection de bots décrit des catégories publiques, pas une table complète de poids permettant de recalculer un score à partir de propriétés du navigateur. Pour une comparaison de confidentialité, consultez groupes de signaux et limites d’observation et le guide des preuves V8Log.

Construire une preuve bornée

Utilisez un identifiant de requête stable et conservez seulement les entrées actionnables. Conservez l’URL source et la version du schéma afin de distinguer une absence d’un jeu de données modifié. Ceci est un gabarit documentaire, pas une sortie Cloudflare observée :

{
  "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."
}

Les valeurs null et l’étiquette source-based-fixture sont intentionnelles : elles évitent de confondre le modèle avec une exportation de zone. Dans un dossier autorisé, remplacez-les par les valeurs reçues, gardez les noms exacts et caviardez URL, cookies, corps, identifiants de compte et en-têtes complets sauf besoin documenté. Distinguez not-enabled, not-in-dataset, null et not-requested. Le Fingerprinting Guidance du W3C explique pourquoi la combinaison de signaux augmente le risque de confidentialité.

Séparer score, défi et résultat HTTP

Utilisez ce tableau lors d’une revue de support ou de mise en production. La règle consiste à attribuer chaque observation à sa couche avant de demander ce qui a changé.

Observation	Peut étayer	Ne peut pas établir	Vérification suivante
BotScore 1-99	Le signal de probabilité documenté par Cloudflare pour la requête	Identité, poids, intention ou verdict universel de bot	Confirmer plan, jeu de données, horodatage et BotScoreSrc
BotScoreSrc ou BotTags	Métadonnées publiques de source ou de tag si présentes	Trace complète du détecteur ou raison de chaque tag	Lire la variable et la version du schéma Logpush
Action challenge	La sélection ou l’exposition d’un workflow de sécurité	Que le demandeur soit malveillant, humain ou vérifié avec succès	Enregistrer séparément résultat du défi et politique applicative
Statut HTTP 200, 403 ou autre	Le résultat observé par le client ou le journal	Pourquoi la réponse a eu lieu, qui l’a déclenchée ou si une personne a réussi un défi	Joindre horodatage, route et action sous un identifiant contrôlé

Les lignes ne s’impliquent pas entre elles. Un score haut suivi de 403 ne prouve pas qu’un humain a été bloqué. Un score bas suivi de 200 ne prouve pas que l’automatisation a été acceptée. Un défi suivi de 200 ne prouve pas qu’une personne l’a résolu. Gardez la séquence et le propriétaire de chaque enregistrement.

Décrire les limites d’inférence

La documentation publique permet de parler du sens et de la portée des champs nommés, pas des poids cachés, du vecteur complet d’entrées ou de l’identité du demandeur. Le glossaire fingerprinting de MDN décrit la combinaison de données navigateur et appareil pour distinguer des utilisateurs ou appareils ; un journal de score ne doit donc pas devenir une empreinte inter-contextes.

Gardez score, challengeAction et httpStatus dans des colonnes distinctes. Écrivez d’abord le fait borné : « le journal contenait le score X dans le jeu Y à l’heure Z ». Écrivez ensuite l’action : « l’application a renvoyé Q après R ». Évitez d’affirmer que Cloudflare savait qu’il s’agissait d’un bot ou qu’une personne a prouvé son humanité. BotBrowser n’expose pas les entrées ou poids privés, ne force pas un défi et ne transforme pas un statut HTTP en identité. Relisez les sources si le schéma ou la disponibilité change.

BotBrowser peut automatiser un flux autorisé et observer l’état visible de la page, comme le décrit sa documentation de cohérence de l’automatisation ; il ne peut pas lire une zone Cloudflare ni produire BotScore, BotScoreSrc et BotTags, qui doivent provenir du produit et du jeu de données configurés dans Cloudflare.

Sources publiques

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

Conclusion pratique

Utilisez le score et les champs publics Cloudflare comme preuves de requête au périmètre défini. Séparez actions de défi et résultats HTTP, documentez disponibilité et heure, puis arrêtez-vous avant d’inférer poids, identité ou intention humaine certaine. Vérifiez le jeu de données et le plan exacts dans les références actuelles avant d’ajouter un champ à un schéma de support.