Canal+ réclamait tout de même 50 000 euros par jour et par site "pirate" encore accessible, et il repart sans rien. Le 17 septembre dernier, le tribunal judiciaire de Paris a rejeté les astreintes demandées contre Cloudflare dans deux dossiers, l'un sur la Formule 1, l'autre sur le MotoGP, ainsi que les 20 000 euros de frais de justice qu'il réclamait en plus.
En avril, ce même tribunal avait tout de même ordonné à Cloudflare de bloquer 21 domaines de streaming F1 et 16 de MotoGP "par tout moyen efficace". Et Cloudflare a choisi le sien : un blocage sur son CDN, pour les sites qui passent par son réseau, et aucun filtrage sur son résolveur DNS public 1.1.1.1. Pas de DNS menteur ou censuré donc... mais Canal+ y voyait un contournement délibéré, puisque seuls 3 domaines sur 21 auraient été bloqués côté F1 (et 3 sur 16 côté MotoGP), dont deux sont revenus en ligne la semaine suivante via un autre CDN ou un site miroir.
Mais le tribunal n'a pas suivi. Selon lui, un intermédiaire technique a une obligation de moyens mais pas de résultat, comme le précise l'arrêt UPC Telekabel de la Cour de justice de l'Union européenne. Cela veut donc dire que Cloudflare ne peut pas être tenu responsable quand un site change de CDN. C'est donc à Canal+ d'aller voir le nouvel intermédiaire et de signaler les miroirs à l'Arcom.
Alors, est-ce que 1.1.1.1 filtre des sites en France ?
Eh bien non les amis, et ça se vérifie très facilement en quelques secondes. Depuis ma connexion bien française, le résolveur de Google (8.8.8.8) refuse de résoudre les domaines de la liste "Premier League" ordonnée en juillet, avec un message qui invoque "une injonction judiciaire ou toute autre mesure administrative de blocage visant FR".
Alors que le 1.1.1.1 de Cloudflare, lui, répond normalement pour les sites encore en ligne. D'ailleurs Cloudflare le confirme bien dans son rapport de transparence du second semestre 2025 : Aucun contenu n'a jamais été bloqué via 1.1.1.1, car un blocage sur un résolveur public mondial s'appliquerait à tous ses utilisateurs, où qu'ils se trouvent.
Après ça ne veut pas dire que changer de DNS suffira à tout débloquer puisque le géoblocage que Cloudflare applique côté CDN limite l'accès au site lui-même depuis la France. Donc passer par 1.1.1.1 n'y changera rien, un site bloqué sur le CDN de Cloudflare ne sera pas accessible via leurs serveurs DNS. Mais par contre, les sites qui passent entre les mailles, ce sont tous les sites hébergés ailleurs que chez Cloudflare, que les FAI bloquent chacun de leur côté, en faisant "mentir" leurs propres résolveurs DNS.
Reste que ce jugement n'a rien d'une carte blanche... Quand Cloudflare explique que l'architecture de son DNS public ne permet pas d'implémenter un blocage, le tribunal se contente d'écrire qu'il "allègue". Mais en réalité, la cour d'appel de Paris avait jugé en mars dernier que le blocage DNS était tout à fait faisable. Et en juillet, dans un dossier sur des médias russes sous sanctions européennes, le Conseil d'État avait relevé que Cloudflare propose déjà gratuitement un résolveur capable de bloquer les logiciels malveillants et les contenus pour adultes...
Voilà, donc comme les ordonnances signées le 17 juillet pour la Premier League et la Ligue des champions visaient nommément le résolveur, le CDN et le reverse proxy de Cloudflare, et qu'elle laissait à l'entreprise américaine le choix des moyens techniques, la messe est dite. Et on n'oublie pas non plus que de son côté, Quad9, la fondation suisse qui ne bloque aucun des domaines visés par beIN Sports, est également sous pression de la part de la chaine de sport qui lui réclame 10 000 euros par jour et par domaine pirate accessible. La décision est attendue d'ici la fin du mois...
Dans tous les cas, si vous êtes sur 1.1.1.1, rien ne bouge pour l'instant... mais ça tient moins à Cloudflare qu'à la façon dont les prochaines ordonnances seront rédigées... On verra bien.
Source : TorrentFreak
Cloudflare a sorti il y a petit moment maintenant une commande que pas mal de dev utilisent et dont je vais vous parler aujourd'hui : cloudflared tunnel --url, qui permet de publier un serveur tournant sur votre machine à une adresse en trycloudflare.com, sans avoir besoin de compte, de nom de domaine et surtout sans avoir à ouvrir le moindre port sur votre box toute pourrie.
Et la petite nouveauté depuis quelques jours, c'est que, autant avant, n'importe qui possédant le lien pouvait se connecter à votre service, mais maintenant, Cloudflare a mis en place une option qui permet de réserver ce lien à quelques adresses e-mail que vous définissez.
Ce service s'appelle les Quick Tunnels, et pour en profiter, il vous faudra juste un service web qui tourne en local (moi je vais faire ça sur le port 8080 comme d'hab) avec une page de test toute bête servie par Python. Voilà c'est juste de quoi vérifier que tout passe bien avant d'y brancher un vrai projet. Et si vous faites bosser des agents IA avec ce truc, on verra aussi comment mettre un garde-fou pour éviter l'exposition sur le web de trucs pas prévus ! Argh !!
cloudflared, c'est le petit connecteur open source de Cloudflare, celui qui établit la connexion sortante vers leur réseau. Sur Mac, pour l'installer c'est fastoche, suffit d'utiliser Homebrew :
Connexionbrew install cloudflared
Sous Debian ou Ubuntu, passez par conte par le dépôt officiel de Cloudflare. Il a changé de clé de signature récemment, donc reprenez bien ces commandes plutôt que celles d'autres vieux tutos qui traînent :
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared
Et sous Windows (les courageux !! lol), la page de téléchargement de Cloudflare propose un MSI ou un exécutable, en 32 ou 64 bits, et le paquet existe aussi chez winget sous l'identifiant Cloudflare.cloudflared. Dans tous les cas, vérifiez ensuite la version, car l'option d'authentification dont on va parler plus bas n'arrive qu'à partir de la version 2026.9.3 :
cloudflared --version
Tout d'abord, lancez votre serveur local, puis dans un autre terminal, faites :
cloudflared tunnel --url http://localhost:8080
Au bout de quelques secondes, cloudflared affichera un encadré avec une adresse aléatoire composée de quatre mots, du genre quelque-chose-truc-bidule.trycloudflare.com, en prévenant qu'elle peut mettre un moment à répondre. Donc soyez un peu patient, le temps que le DNS résolve ce truc (et
videz votre cache DNS
si ça veut vraiment pas le faire).
Ensuite, ouvrez cette URL depuis un autre appareil, genre votre téléphone en 4G par exemple et hop, vous tomberaz sur votre serveur local. Et si vous voulez tout couper, un petit Ctrl+C dans le terminal et c'est fini ! Pas de panique, au prochain lancement de cloudflared, vous aurez une nouvelle adresse.
La commande de base, et le cadre où cloudflared affiche l'adresse trycloudflare.com à partager
Notez aussi que le port n'est pas imposé puisque --url accepte tout ce que cloudflared peut joindre, une adresse IP de votre réseau local comprise. Par contre, si votre projet tourne sous Vite, vous allez prendre un "Blocked request" en pleine tronche, car Vite ne répond par défaut qu'à localhost, aux domaines en .localhost et aux adresses IP. La parade la plus simple consiste donc à faire croire à Vite qu'on l'appelle via localhost:5173 en faisant comme ceci :
cloudflared tunnel --url http://localhost:5173 --http-host-header localhost:5173
L'autre solution, c'est d'ajouter l'hôte dans le réglage server.allowedHosts de Vite. Mais évitez de passer ce réglage à true pour aller plus vite, en effet
la doc de Vite
le déconseille puisque ça expose votre serveur de dev à des attaques par DNS rebinding. Oupsi oups !
Gardez aussi en tête que c'est un outil de test et de démo et que c'est pas fait pour de la prod. Si on en croit la doc , Cloudflare ne garantit aucune disponibilité, sans oublier que chaque tunnel encaisse au max 200 requêtes en simultanné (au-delà, ça vous fera une erreur 429 ) et les Server-Sent Events ne passeront pas. Voilà, donc si vous voulez un nom fixe et du vrai trafic, il faudra plutôt créer un tunnel nommé à partir d'un vrai compte Cloudflare et d'un domaine de votre choix.
Et maintenant, pour limiter l'accès à votre service à quelques personnes, ajoutez --allowed-mail suivi de l'adresse email de celui à qui vous voulez montrer votre merveilleux boulot :
cloudflared tunnel --url http://localhost:8080 --allowed-mail korben@example.com
L'encardré change alors de "ton" en vous annonçant que le tunnel est "protégé" par une authentification de type code à usage unique via Cloudflare Access, ainsi que la quantité d'adresses autorisées. Les adresses elles-mêmes n'apparaissent nulle part, même dans la ligne des réglages où elles sont remplacées par des astérisques, ce qui est plutôt bien vu si vous faites une démo en mode partage d'écran. Ça évite les fuites de données perso !
Avec --allowed-mail, le cadre annonce le code à usage unique et le nombre d'adresses autorisées, sans jamais les afficher
Vous pouvez ensuite répéter l'option autant de fois que nécessaire, séparer plusieurs adresses par des virgules, ou autoriser tout un domaine. Mettez simplement des guillemets autour du "joker" (c'est l'étoile) pour que votre misérable shell ne tente pas de l'interpréter comme un gros teubé :
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail korben@example.com \
--allowed-mail bob@example.com \
--allowed-mail '*@example.com'
Côté Wrangler, si vous bossez sur Workers, un petit npx wrangler tunnel quick-start acceptera la même option :
npx wrangler tunnel quick-start http://localhost:8080 --allowed-mail korben@example.com
De son côté, votre invité VIP n'aura alors plus qu'à ouvrir l'URL que vous lui avez donné et cloudflared renverra son browser vers login.trycloudflare.com. Il tombera alors sur une page Cloudflare Access qui lui demandera son adresse mail. Il recevra ensuite un code dans sa boîte, devra le taper, et arrivera enfin (ouf !!) sur votre merveille application probablement vibe codée (lol).
Et quelqu'un qui n'est pas sur la liste des invité ne verra quand à lui qu'une réponse de base lui expliquant qu'il peut bien aller se faire voir (et sa requête n'atteindra jamais votre application).
Ce que voit votre invité en ouvrant l'URL protégée : la page Cloudflare Access qui lui demande son adresse mail
Et votre liste d'emails, elle, n'est jamais diffusée hors de votre ordi puisque Cloudflare vérifie seulement que la personne contrôle l'adresse qu'elle a saisie. Ensuite c'est cloudflared qui compare les accès en mémoire, avec ce que vous avez tapé. Une fois entré, le visiteur gardera alors sa session jusqu'à 4 heures max.
Et si vous voulez modifier cette liste d'accès, il faudra alors arrêter le tunnel et en relancer un autre, ce qui coupera l'accès à tout le monde et vous donnera une nouvelle adresse à renvoyer. Donc soyez sûr de votre coup avant de casser la tête aux gens qui vont tester votre appli.
Sachez aussi que cette vérification ne pourra se faire qu'avec un vrai navigateur et pas des trucs du genre un webhook Stripe, un GitHub, un script en curl ou encore n'importe quel client automatique qui restera coincé devant cette page de connexion.
Pour ces cas-là précieusement, je vous recommande plustôt d'ouvrir un tunnel public le temps du test et de le couper juste après. Et si le webhook doit tourner durablement, passez sur un tunnel nommé avec Cloudflare Access, sur votre propre domaine.
Maintenant, parlons un petit peu à agents IA parce que oui... Un agent de code a besoin d'un endroit pour vous montrer ce qu'il vient de faire de beau, et Cloudflare décrit justement ce cas de figure dans son article.
Pour éviter qu'un agent IA ne diffuse publiquement ce qu'il vient de faire à la vue de tous, ce que recommande Cloudflare, c'est donc d'ajouter une ligne dans le fichier d'instructions de l'agent AGENTS.md comme ceci :
Quand tu lances un Quick Tunnel, ajoute toujours --allowed-mail moi@exemple.fr.
Sauf qu'une consigne reste une consigne... C'est un prompt que l'agent peut choisir d'ignorer... Donc gardez bien en tête que ces fichiers sont traités comme du contexte et pas comme une configuration imposée.
Maintenant, si vous voulez vraiment bloquer une action, peu importe ce que décide le modèle, ce que je vous recommande d'utiliser à la place, c'est un hook "PreToolUse". Moi, j'en mets partout dans mes configs Claude Code pour plus de sécurité.
Si vous ne savez pas ce qu'est un hook, en fait c'est un petit script contenant la commande en JSON, et que Claude Code lance avant chaque commande bash. Si ce script se termine avec le code "2" l'appel est alors bloqué. Pour faire ça, il faut donc créer dans le dossier .claude/hooks/ de votre projet, le script suivant :
#!/bin/bash
# .claude/hooks/tunnel-protege.sh
COMMAND=$(jq -r '.tool_input.command')
if echo "$COMMAND" | grep -qE 'cloudflared.*tunnel.*--url|wrangler.*tunnel.*quick-start' \
&& ! echo "$COMMAND" | grep -q -- '--allowed-mail'; then
echo "Quick Tunnel public refusé : ajoutez --allowed-mail, ou demandez-moi d'abord." >&2
exit 2
fi
exit 0
Puis rendez-le exécutable avec chmod +x, et installez jq si vous ne l'avez pas encore fait.
Déclarez-le ensuite dans le .claude/settings.json du projet, sur l'outil Bash comme ceci :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/tunnel-protege.sh"
}
]
}
]
}
}
Maintenant, si ça vous prend trop le chaud de faire ça, sachez que j'ai fait un petit kit à télécharger ici, pour les Patreons :
Ensuite, à partir de là, un cloudflared tunnel --url ou un wrangler tunnel quick-start lancé sans le paramètre --allowed-mail ne fonctionnera pas, et l'agent recevra le message du hook qui lui dira d'ajouter l'option ou de vous demander s'il doit y avoir un contournement.
Et bien sûr, un tunnel nommé lancé avec cloudflared tunnel run, lui, passera normalement.
Comme d'hab, ce genre de garde-fou a ses limites, puisqu'il ne lit que le texte de la commande et ne vérifiera pas l'adresse qui suit l'option. Il ne verra non plus les tunnels qui pourraient être lancés depuis un script ou à l'aide d'une variable d'environnement TUNNEL_URL, qui permet aussi de lancer un Quick Tunnel. Voilà, donc laissez la consigne dans AGENTS.md en plus du hook, au cas où... Les deux devraient bien se compléter.
Pour les soutiens Patreon , le kit ci-dessus reprend donc ce hook avec les consignes à coller dans AGENTS.md, dont l'exception des clients automatiques (l'agent vous demande au lieu de retirer l'option).
Il y a aussi là dedans un script qui lance le tunnel protégé et ne renvoie que son adresse. Et si vous préférez scripter ça vous-même, partez de --output json, qui transformera chaque ligne du log en objet JSON. L'adresse sera alors accessible dans le champ message, et vous pourrez alors l'extraire avec une expression régulière.
Ah et un dernier point avant de lâcher un agent là-dessus sur le portable de votre boulot, je vous invite à lire ce que Proofpoint a documenté concernant des campagnes de malware qui s'appuient sur ce genre de tunnels gratuits. Ça explique pourquoi des outils de sécurité comme Elastic ont des règles qui repèrent cloudflared quand il est utilisé pour exposer un service local. Leur conseil c'est de bloquer les domaines de tunnel quand l'usage n'est pas autorisé, donc si vous comptez utiliser ça dans votre boite, allez voir Dieu Tout Puissant (le sysadmin grognon quoi...) pour lui demander l'autorisation. Il va pester, souffler, éventuellement vous cracher dessus puis finira probablement par accepter, donc pas d'inquiétude ^^.
Et comme la protection par mail est gratuite, au même titre que les Quick Tunnels eux-mêmes, je ne vois aucune raison valable de balancer une démo accessible sur le web sans utiliser cette authentification.
Cloudflare a un nouveau terrain de jeu : le voilà qui veut devenir une autorité de certification publique.
Il a soumis sa propre clé racine aux principaux magasins de confiance du marché (Chrome, Apple, Microsoft, Mozilla). Comme la procédure d’inscription peut prendre plusieurs années, il en a aussi racheté une à GlobalSign. Existant depuis 2012, elle lui permettra une couverture plus rapide… et aussi plus large. En ligne de mire, les terminaux anciens arrivés en fin de support et que sa racine aurait par là même du mal à atteindre.
Cloudflare promet une alternative à Let’s Encrypt. Son argument : cette autorité, qui émet aujourd’hui près de 40 % des certificats TLS publics, induit un risque systémique. En cas d’incident, il n’existe pas de concurrent capable d’absorber la charge gratuitement et de manière automatisée.
À défaut d’avoir émis jusque-là ses propres certificats, Cloudflare peut revendiquer une expérience en tant que mandataire. Pour chaque domaine configuré sur son réseau, il obtient des certificats auprès d’autorités partenaires. Cela lui a, affirme-t-il, permis de saisir les faiblesses du Web PKI (plafond de requêtes, lenteur des révocations massives, changements de politiques chez les CA…).
Cloudflare anticipe plus globalement une croissance de la demande en certificats pour trois raisons principales. Parmi elles, le raccourcissement de leur durée de vie, impulsé en particulier par Apple et Google. Il y a aussi l’activité des agents autonomes, qui entraîne une prolifération de microservices nécessitant des identités cryptographiques propres.
La troisième raison, c’est la transition post-quantique. Cloudflare veut faire partie des premières autorités de certification à prendre ce train. Il vise une admission début 2027 dans le programme spécifique récemment ouvert par Chrome.
La démarche reposera sur les MTC (Merkle Tree Certificates), qui se sont imposés, dans l’écosystème, comme la solution technique de référence. Ils font l’objet d’un projet de spécification au sein de l’IETF. Dans les grandes lignes, plutôt que de signer chaque certificat feuille individuellement, on les insère par lots dans un arbre de Merkle dont on signe la racine. Les clients n’ont alors qu’à vérifier une preuve d’inclusion (suite logarithmique de hachages cryptographiques).
Les MTC réutilisent le conteneur standard X.509 en y insérant un identifiant d’algorithme de signature. Ils sont délivrés de deux manières. Dans la forme dite autonome, le certificat embarque tout ce dont le client a besoin. Dans celle dite « avec repère », l’autorité de certification regroupe l’ensemble de ses certificats actifs sous forme d’une série de sous-arbres, formant une référence temporelle commune. Le clients reçoivent en amont, hors bande, les têtes d’arbre signées. Le serveur ne transmet alors que la preuve d’inclusion, éliminant les signatures post-quantiques de la négociation TLS. Ce mécanisme permet qu’une poignée de signatures sécurise des milliards de certificats. Il suppose toutefois de pouvoir mettre à jour les clients. D’où le besoin de conserver le mode autonome.
Cloudflare fondera son infrastructure sur un fork de Boulder, utilisé par Let’s Encrypt. Les flux d’émission reposeront sur le protocole standard ACME. Ils impliqueront – spécificité de l’ère MTC – des cosignataires indépendants. Ceux-ci stockeront une copie des journaux d’émission et vérifieront que l’arbre grandit strictement en ajout seul, sans bifurcation frauduleuse.
Seulement après validation d’un cosignataire externe, l’autorité de certification pourra assembler l’objet MTC final. Lequel contiendra les cosignatures, la clé publique du serveur demandeur et la preuve d’inclusion Merkle.
Parallèlement, Cloudflare projette une évolution du système de transparence du Web PKI. Il impose à chaque autorité de soumettre tout certificat à au moins deux registres publics. Il n’est cependant pas natif à X.509. Son ajout a posteriori engendre des inefficacités ; à commencer par le multi-enregistrement fréquent des certificats. Leur coût va se révéler d’autant plus important avec les signatures post-quantiques, les volumes à ingérer étant amenés à augmenter nettement (x 40, d’après Cloudflare).
Sous l’ère MTC, il s’agira de faire de ce mécanisme une propriété native. Le registre ne stockerait que des hachages de clés publiques et la signature sur la tête d’arbre couvrirait mathématiquement l’intégralité du log.
Une expérimentation a été menée auprès de 50 % des utilisateurs de la bêta de Chrome 146. Cloudflare a déployé une fausse autorité délivrant, pour un échantillon des sites hébergés sur son plan gratuit, des MTC adossés à une chaîne de certificats conventionnelle.
Sur des milliards de certificats servis, la négociation TLS en mode autonome s’est révélée 9 % plus rapide qu’avec une chaîne de signatures classique. Cloudflare admet qu’en l’état, l’essentiel du gain provient de l’élision des certificats intermédiaires. Cependant, ayant testé les MTC avec des signatures classiques, il dit attendre, en post-quantique, un gain nettement supérieur.
Pour éviter de recréer un goulet d’étranglement, il faudra que des opérateurs de cosignature émergent. Et, plus simplement, que d’autres CA passent au régime post-quantique…
Illustration générée par IA
The post Cloudflare se projette en Let’s Encrypt post-quantique appeared first on Silicon.fr.
Cloudflare a mis en ligne sur son GitHub un skill trop super génial d'audit de sécurité qui leur a servi de point de départ à leur propre système de chasse aux failles de sécu. Ce package pour faire des audits de sécu boostés à l'agent IA c'est un dossier de consignes en Markdown que vous déposez dans votre agent de code, et qui le fait bosser comme un vrai auditeur et pas simplement comme un "relecteur" de code.
Dans ce dépôt, vous trouverez un fichier par famille d'attaque : la corruption mémoire, l'injection de prompt, le cadrage des requêtes HTTP, l'isolation entre locataires. Et avec ça, un schéma JSON qui décrit à quoi doit ressembler un rapport, et deux validateurs écrits en JavaScript sans la moindre dépendance.
Le dossier du skill sur GitHub : un fichier de consignes par famille d'attaque, et les deux validateurs en bas de liste ( Source )
L'agent déroule ensuite six phases, de la reconnaissance au rapport final. Il commence par cartographier l'architecture, les frontières de confiance et les points d'entrée, puis il écrit sa propre grille de couverture. Ensuite il envoie des chasseurs isolés case par case et chaque piste qui remonte part chez un vérificateur tout frais tout beau qui n'a pas participé à la chasse.
Chaque piste se termine ensuite avec un rapport technique. Un rapport confirmed qui exige une trace source complète et un résultat réellement observé. Un rapport needs_validation qui nomme le fait précis qui manque, et surtout qui n'a droit à aucun niveau de gravité. Et le rapport des rejected qui garde la mémoire de ce qui a été réfuté, pour que la passe suivante ne vous ressorte pas la même chose.
Le validateur, lui, c'est du vrai code qui vérifie la "forme" de la preuve. Les empreintes doivent être uniques, et le suivi du parcours des tests qui doit partir d'un point d'entrée pour finir sur un point d'impact. Ainsi une trouvaille confirmée dont le parcours ne tient pas debout est recalée.
En revanche, sachez-le, l'indépendance du vérificateur est demandée dans les consignes, mais pas contrôlée (chez Cloudflare, c'est leur orchestrateur maison qui s'en charge, et il n'est pas dispo publiquement).
Cloudflare explique sur son site ce que donne un de ces agents lâché sur du code sans garde-fou. Il modifie la source pour que son exploit fonctionne, puis il annonce fièrement le bug qu'il vient de créer lui-même. Ou alors il pond un test qui démontre que exec() exécute des choses, donc que c'est forcément une faille critique... Et ça vous l'aurez compris, c'est de la merde et c'est absolument ce qu'on ne veut pas.
Voilà donc exactement ce que ces consignes cherchent à lui interdire.
Pour l'installer, il vous faut le CLI skills de Vercel Labs :
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Ensuite, vous lancez votre agent dans le dépôt à auditer et vous lui demandez un audit de sécurité. Le skill se déclenche tout seul et c'est le modèle de votre agent qui pilotera les sous-agents en parallèle (utilisez donc un modèle qui sache faire ça, c'est mieux lool). Par défaut, le rapport atterrit ensuite dans un dossier ~/security-audit-skill, en dehors du dépôt audité.
Ce qui est cool c'est que ce skill est conçu pour limiter les bêtises. Par exemple il refuse d'exécuter le code qu'il audite s'il n'a pas de bac à sable (sandbox) imposé par le système d'exploitation, avec le réseau coupé, la cible en lecture seule et des limites de CPU et de mémoire. Ce bac à sable, le dépôt ne le fournit pas, et c'est à vous de le mettre en place avec par exemple
un outil d'isolation comme Fence
. Sans lui, la piste de l'audit finira tout bonnement en needs_validation au lieu d'être véritablement suivie et tranchée.
Après, c'est le temps qui fera la différence. Chez Cloudflare, ils ont un gros système qui leur permet, par exemple avec un dépôt d'environ 30 000 lignes de code, de ne passer que 3 à 4 heures sur l'audit pour avoir un résultat correct. Mais chez vous, en local, ce sera beaucoup plus long. Cloudflare prévient aussi qu'une seule passe n'est pas suffisante puisqu'elle trouve à peu près la moitié des failles à chaque fois. Il faudra relancer ça plusieurs fois.
Allez, si vous cherchez également un filet de sécurité pour tout ce qui concerne vos pull requests, sachez qu'Anthropic maintient de son côté un reviewer de sécurité pour Claude Code qui lit le diff et vient commenter directement dessus.
Le dépôt de Security Audit Skill de Cloudflare est sous licence MIT, et il lui faudra Node.js pour faire tourner ses deux validateurs.
En tout cas, ce que je vous conseille, c'est d'aller lire le SKILL.md avant de lancer la première passe, pour vous assurer que tout sera OK au sein de votre harness.
Source : security-audit-skill sur GitHub
Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.
Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.
Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.
Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.
Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.
Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.
Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.
Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.
Il faut un compte Cloudflare, évidemment...
Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.
Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).
Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.
Tout commence en mars 2026, lors d’une opération de surveillance routinière.
Les équipes de Cloudforce One, la division de renseignement sur les menaces de Cloudflare, détectent une anomalie dans des scripts Workers déployés sur la plateforme serverless de l’entreprise.
Parmi ces scripts, utilisés pour mettre en place des tunnels de proxy VPN via le protocole VLESS, l’un d’eux contient des milliers de lignes de commentaires répétitifs, rédigés en plusieurs langues. Il s’agit de des blocs de texte en langage naturel destinés non pas aux développeurs humains, mais aux systèmes d’intelligence artificielle chargés d’auditer le code.
Ces commentaires constituent ce que les chercheurs appellent des leurres de sécurité « Notice to AI » ». Soit des instructions dissimulées dans du code, conçues pour convaincre un modèle d’analyse automatisée que le script est inoffensif.
C’est la définition même de l’injection de prompt indirecte (Indirect Prompt Injection, ou IDPI), un vecteur d’attaque qui cible non plus les systèmes traditionnels, mais la couche de raisonnement des LLM utilisés comme outils de sécurité.
Suite à cette découverte, Cloudforce One a lancé une étude systématique pour évaluer l’impact réel de cette technique sur les capacités de détection des modèles.
Dans une première phase, les chercheurs avaient testé de courts extraits de code (environ 2 000 tokens), concluant que les leurres étaient largement contre-productifs : pour la plupart des modèles non-frontier, une accumulation de fausses déclarations de sécurité agissait comme un signal d’alarme, augmentant la détection plutôt que de la réduire.
Mais cette première phase laissait deux variables critiques non explorées : la saturation et le contexte. Un attaquant réel ne se contente pas d’insérer un bloc de texte en début de fichier ; il peut disperser ses commentaires tout au long du script, et l’auditeur IA analyse le fichier complet, pas seulement les premières lignes.
La phase 2 a donc été conçue pour combler ces lacunes :
Sept modèles ont été évalués, répartis en deux catégories : les modèles non-frontier (rapides, optimisés pour le coût) et les modèles frontier (systèmes de pointe avec raisonnement avancé).
L’étude révèle un phénomène contre-intuitif. L’efficacité des leurres suit une courbe en U selon le volume de commentaires injectés. Un volume modéré (1 à 20 commentaires) suffit à abaisser significativement les taux de détection des modèles non-frontier les plus vulnérables. Le taux de détection du modèle non-frontier le plus faible chute de 90 % à 67 %.
Mais à l’extrême opposé (1 000 commentaires ou plus), la stratégie se retourne contre l’attaquant. La répétition massive déclenche ce que les chercheurs appellent une « alarme de répétition », et la plupart des modèles finissent par reconnaître cette saturation comme un signe caractéristique de fraude.
Le constat le plus opérationnel concerne non pas le nombre absolu de commentaires, mais leur ratio par rapport au code fonctionnel.
Lorsque les leurres représentent moins de 1 % du fichier total, ils sont les plus efficaces. Le taux de détection moyen sur l’ensemble des modèles testés s’effondre à 53,3 %, contre 67,3 % en conditions normales. Les commentaires sont alors suffisamment discrets pour influencer subtilement le raisonnement du modèle sans déclencher de suspicion.
À l’inverse, dès que les commentaires dépassent 25 % du fichier, ils deviennent une signature à haute valeur discriminante : le taux de détection remonte à 99 %, les modèles interprétant cette surreprésentation comme un indicateur clair d’intention malveillante.
La découverte la plus significative de l’étude dépasse la problématique des leurres linguistiques. Quelle que soit la sophistication des commentaires injectés, c’est la taille des fichiers qui constitue le facteur de risque le plus important.
Pour des scripts Workers inférieurs à 500 Ko, les taux de détection approchent les 100 %. Pour des fichiers dépassant 3 Mo ( notamment des bundles de bibliothèques légitimes comme les SDK TON ou React ), ce taux s’effondre à seulement 12 à 18 %.
L’explication est double. Soit le code malveillant se retrouve hors de la fenêtre de contexte du modèle, soit il est tellement dilué par du code bénin environnant que l’attention du modèle ne parvient plus à l’isoler.
Dans ce deuxième cas, même lorsque l’ensemble du fichier tient dans la fenêtre de contexte, la logique malveillante ( par exemple, une exfiltration de données vers Telegram) reste indétectable, noyée dans des milliers de lignes de code légitime.
L’étude met également en évidence des stéréotypes linguistiques développés par les modèles. Lorsque les scripts contiennent 1 000 commentaires dans différentes langues, les réactions varient sensiblement :
Ces stéréotypes linguistiques constituent à la fois un levier potentiel pour les attaquants — en choisissant la langue la moins susceptible de déclencher des alertes — et un risque de faux positifs pour les défenseurs.
Un dernier phénomène mérite l’attention des équipes de sécurité.
Face à un volume extrême de commentaires (1 000 et plus), certains modèles frontier n’ont pas été trompés, mais ont cessé de fonctionner correctement : au lieu de rendre un verdict binaire « malveillant / bénin », ils ont produit des réponses mal formatées ou des refus.
Dans un pipeline de sécurité automatisé qui repose sur des sorties JSON structurées pour déclencher des blocages, cette paralysie fonctionnelle équivaut à un contournement.
L’attaquant n’a pas besoin de convaincre l’IA que son code est sûr ; il lui suffit de la rendre incapable d’émettre une commande de blocage.
Pour renforcer les pipelines d’audit IA, les chercheurs proposent plusieurs mesures concrètes :
L’étude de Cloudforce One apporte une nuance importante au débat sur les risques de l’injection de prompt. Si la tromperie linguistique reste une menace réelle, notamment dans la « zone de contournement à 1 % », les modèles frontier s’avèrent globalement plus résistants qu’attendu face aux leurres textuels.
La véritable vulnérabilité se situe dans la capacité des attaquants à noyer un payload malveillant dans un volume de données légitimes suffisant pour saturer l’attention des modèles.
En d’autres termes, les adversaires n’ont plus besoin de convaincre l’IA que leur code est sûr. Ils ont seulement besoin de rendre le signal malveillant trop faible pour être détecté.
The post Les IA de sécurité, nouvelles cibles de l’injection de prompt appeared first on Silicon.fr.
Désormais, plus de la moitié des bots sont spécifiquement destinés à entraîner des IA.
Cette statistique ne vaut peut-être pas pour le web dans son entièreté. Elle vaut en tout cas pour le réseau Cloudflare*. Sur les 7 derniers jours, le taux de bots « spécial entraînement » a dépassé les 52 %, contre 8 % dédiés à la recherche et 37 % ayant des finalités mixtes.
Cette part est en progression. Si on étend la fenêtre aux 3 derniers mois, elle avoisine 49 %. En élargissant sur les 6 derniers mois, elle tombe autour de 44 %. Et sur les 12 derniers mois, sous les 40 %.
Sur le « top 10 000 » des domaines connectés à son réseau, Cloudflare a pu analyser 4094 fichiers robots.txt.
GPTBot y est le bot le plus souvent bloqué (au moins partiellement). Suivent CCBot (de Common Crawl), ClaudeBot, Google-Extended et Bytespider (de ByteDance, éditeur de TikTok).
GPTBot est, en même temps, le troisième bot le plus souvent autorisé (au moins partiellement), devant PerplexityBot et ChatGPT-User (qui visitent tous deux des pages web en réponse à des requêtes d’utilisateurs).
Sur les sites étiquetés « Technologie » (926 fichiers robots.txt), on bloque surtout GPTBot (70 occurrences), CCBot (67) et ClaudeBot (59).
On autorise avant tout PerplexityBot (58), GPTBot (57) et Googlebot (52).
En catégorie « Business » (797 fichiers), on bloque avant tout GPTBot (55), Amazonbot (51) et ClaudeBot (50).
On autorise essentiellement GPTBot (46), Googlebot (42) et PerplexityBot (41).
En catégorie « E-commerce » (291 fichiers), les plus bloqués sont Googlebot (44), ClaudeBot (40) et GPTBot (40).
Les plus autorisés sont Googlebot (35), bingbot (20) et OAI-SearchBot (20 ; dédié à l’indexation de contenus pour ChatGPT).
En catégorie « Actualités/Médias » (183 fichiers), les blocages portent principalement sur CCBot (81), GPTBot (76) et ClaudeBot (71). Les autorisations, bien moins nombreuses, sur Googlebot (22), OAI-SearchBot (19) et GPTBot (19). Elles sont souvent partielles.
Cloudflare propose un outil pour évaluer si un site est « prêt pour les agents ». Parmi les « 200 000 principaux domaines » testés, il en a retenu un échantillon de 109 415 et y a mesuré le niveau d’implémentation de diverses technologies.
78 % de ces domaines ont un fichier robots.txt ; 63 %, un sitemap.
Ils sont 17 % à avoir intégré des règles IA dans robots.txt. 9 % exploitent les en-têtes Link, qui permettent de sérialiser plusieurs liens – et ainsi, typiquement, de pointer vers des métadonnées relatives à la ressource demandée.
On tombe à 6 % pour la négociation Markdown. Il s’agit d’une initiative de Cloudflare. Le principe : exploiter les en-têtes de négociation de contenu pour effectuer, à la source, une conversion du HTML en Markdown, format plus adapté aux IA.
On est également autour de 6 % pour la découverte OAuth. La spec sous-jacente (RFC 8414, Authorization Server Metadata) permet au client de rechercher les informations nécessaires pour interagir avec un serveur OAuth.
L’Universal Commerce Protocol, que Google propose pour encadrer le commerce agentique, a un taux d’adhésion d’un peu plus de 5 %. On en est à 4,5 % pour une autre techno made in Cloudflare : Content Signals. Cette extension de robots.txt implémente un mécanisme pour expliquer aux systèmes automatisés comment utiliser du contenu. Elle s’appuie sur trois signaux pour autoriser respectivement la construction d’un index de recherche, l’exploitation du contenu en tant qu’input pour des réponses générées en temps réel et son utilisation pour l’entraînement ou le fine-tuning.
L’adhésion est quasi nulle (< 0,1 %) pour les briques suivantes :
Cloudflare a catégorisé les 109 415 domaines en attribuant à chacun une ou plusieurs étiquettes sectorielles. Ci-dessous, un aperçu de l’adoption des différentes technologies dans les dix catégories les plus fournies. Nous nous limitons à celles pour lesquelles le taux atteint au moins 1 %.
| Règles IA | En-têtes Link | Content Signals | Négociation Markdown | Universal Commece Protocol | Découverte OAuth | |
| Technologie (46 239 domaines) |
4,6 % | 5,2 % | 1,6 % | 1,5 % | ||
| Business/économie (25 257) | 2,5 % | 3,3 % | 1, 2% | |||
| Divertissement (23 747) | 5,8 % | 1,9 % | 1,2 % | |||
| Business (19 768) | 1,9 % | 2,8 % | 1,1 % | |||
| Shopping/enchères (18 530) | 3,1 % | 4,2 % | 4,1 % | 4,1 % | ||
| E-commerce (15 964) | 2,5 % | 4,1 % | 4,1 % | 4 % | ||
| Éducation (14 829) | 2,4 % | 1,1 % | ||||
| Société/lifestyle (13 716) | 2,2 % | 3,2 % | 3,2 % | 3,3 % | ||
| Automobile (7834) | 1,8 % | |||||
| Actualités/médias (6951) | 2,2 % |
Sur la base du trafic vers le résolveur DNS 1.1.1.1, chatgpt.com a brièvement fait partie des 10 domaines les plus populaires, vers la mi-avril.
Si on trie par services, ChatGPT/OpenAI est apparu dans le top mondial 10 mi-février. Il s’y est globalement maintenu jusqu’à mi-avril. La situation est similaire sur le périmètre France.
Si on mesure le nombre de clients uniques connectés, le .ai a été, sur les 12 derniers mois, le 13e TLD le plus populaire. Créé en 1995, il est rattaché à Anguilla, territoire britannique des Caraïbes de moins de 20 000 habitants. En mars, il a atteint le million de domaines enregistrés.
* Cloudflare affirme qu’environ 20 % du web est connecté à son réseau.
Illustration principale générée par IA
The post Le web s’approprie lentement les briques censées l’ouvrir aux IA appeared first on Silicon.fr.
