Derrière la récente panne Cloudflare, une mesure de protection contre la faille React

Derrière la récente panne Cloudflare, une mesure de protection contre la faille React

crédits : Unsplash

Deux semaines après une grande panne de plusieurs heures, Cloudflare a de nouveau rencontré un problème de configuration, aboutissant à une coupure de 25 min de ses services. La faute serait relative à un changement intervenu pour combattre l’exploitation de la faille dans React.

Le 08 décembre 2025 à 09h13

Commentaires (17)

votre avatar
Franchement, une panne dans un système aussi complexe pour améliorer la sécurité face à une menace dangereuse très récente c'est okay pour moi.
Nombre de fois au boulot où j'entends, on va pas mettre à jour ça pourrait casser certains clients même si c'est une mise à jour de sécurité importante. Ca fait limite plaisir.
Enfin, je tiens pas non plus un site de e-commerce où 25min de panne signifie -200 000€ de ventes.
votre avatar
Je ne suis qu'à moitié d'accord.

Oui, il faut protéger tes clients contre les alertes de sécurité quand tu leur vends la fonction.
Cela comporte des risques et ils ont mis en place des mécanismes pour les détecter en faisant un déploiement progressif et désactiver une règle si besoin.
Mais ces mécanismes doivent être sans bugs, c'est-à-dire testés à 100 %. Le bug qui a tout fait planté était quand même un bug tout con d'un résultat inexistant parce que l'on n'a pas exécuté un bout de code. C'est même le genre de bug qui doit être détecté par un analyseur de code.

Le fait que l'action de désactiver la règle a été poussée immédiatement partout au lieu de l'être progressivement n'a pas aidé puisqu'elle a produit de gros dégâts immédiatement chez touts les clients concernés. Si elle avait été poussée progressivement, ils auraient vu le problème et serait revenus en arrière sur la modification initiale ce qui aurait produit bien moins de dégâts.
votre avatar
Je dirais que c'est un peu le pb des langages interprétés ou ce type d'erreur ne se voit qu'à l’exécution de la branche de code concernée. Tout juste si un check syntaxique basique est fait au chargement par l'interpréteur, loin du niveau de correction résultant d'un programme qui compile (surtout avec des options peu permissives) et qui est déjà loin d'être une validation que cela fait ce qu'on attends.

Ayant un gros background de C dans un contexte bas niveau, franchement, à chaque fois que je fais du Python même si j'en ai un usage limité/outils perso ou Bash serait à l'agonie et/ou peu lisible/maintenable, j'en arrive à repasser des "linter" comme on le faisait au début des années 90 en école d'ingé, quand la compilation du moindre exo de TD prenait qq minutes sur les stations d'époque... pour afficher les erreurs de base qu'un lint sortait en qq secondes!

Et si, en python, on a des outils comme ruff qui font un excellent boulot (et très vite comparé à d'autres outils plus anciens, qu'il fallait en prime pas mal configurer pour pas faire chier sur les règles de nommage que je trouve débile et que ce langage recommande, Guido ayant eu des fixettes un peu directivistes, certains raccourcis de traitement d'exception globaux et autre trucs qui dans mon cadre d'usage sont voulus)... Eh bien, pour faire un peu de Lua à titre perso (c'est le langage nativement intégré à Domoticz qui gère ma baraque), je l'ai pas trouvé grand chose dépassant luacheck qui fait globalement le job mais laisserait passer le gag Cloudflare.

Pour les pythonistes qui connaissent pas ruff, l'essayer c'est l'adopter!
https://docs.astral.sh/ruff/
votre avatar
Le problème des langages de script et un peu trop dynamique sur le typage, c'est que cela amène un tas de programmeurs du dimanche. Mais bon le marché a besoin de tocards pour faire pression sur les prix. C'est un choix : 'Sécure ou pas cher'...
votre avatar
Ce n'est pas qu'un pb de typage qui facilite la vie (au point de ne plus forcément avoir conscience de ce qu'on manipule), mais que des gags énormes peuvent rester invisibles dans des branches presque jamais utilisées (les cas d'erreur typiquement), jusqu'à ce qu'on y passe, car les interpréteurs ne regardent globalement pas trop ce qu'on leur donne à manger (sans doute pour ne pas ajouter trop de latence au chargement des scripts).
votre avatar
Je confirme les "programmeurs du dimanche".
Et le top du top, c'est les langages qui gèrent le typage stricte mais qui laisse la possibilité au développeur de désactiver ça. Le code n'est plus vérifié à la compilation mais au moment de l'exécution.

Ah VB.Net et ses options Strict / Explicit désactivés ...
votre avatar
However, we have never before applied a killswitch to a rule with an action of “execute”
Mais ils n'ont jamais testé le code non plus.
Un test de couverture de code aurait montré le problème avant qu'il ne se produise en production !

Le bug était quand même assez basique.
votre avatar
La prod est la meilleure des recettes.
votre avatar
Bref, chez Cloudflare, ça déploie en prod un peu à la va-vite... C'est bien de savoir déployer en quelques secondes ; mais c'est mieux si on teste un peu avant de déployer.
votre avatar
Tester c'est douter !
votre avatar
Pourtant, une mise en prod un vendredi... :non:
https://www.estcequonmetenprodaujourdhui.info/
votre avatar
En même temps, un système planté est un système qui n'est pas sujet à la faille en question ! CQFD

Et je suis déjà parti très très loin
votre avatar
L'éternel problème du manque de standardisation. On laisse tellement de possibilités que même en faisant des tests il y aura un cas tordu en prod qui ne marchera pas auquel personne n'aurait pu pensé.
votre avatar
Standardisation de quoi ?
votre avatar
Paramétrage, matériel etc...
Les admins testent sur leurs cas à eux, si ailleurs c'est pas le même paramétrage, le même matériel ça pose vite des problèmes, ils ne peuvent pas deviner les tous les cas utilisés.
Il faut donc standardiser pour éviter cela. Pour que tout soit testable il faut limiter les cas en imposant des standards.
votre avatar
C'est plutôt le contraire. Tu veux tester tous les cas ? Exit les standards, tu contrôles tout et c'est bon (philosophie d'Apple, qui verrouille complètement son matériel).

Si tu respectes des standards (pour la conception de machine j'entends) et c'est vite la merde car justement, tu ne peux pas tout tester (cf. Microsoft).

Imposer un standard fera que tu auras une multiplication des cas d'usage, ce qui va aller à l'encontre du but que tu recherches justement via un testing exhaustif.
votre avatar
Je ne vois pas le rapport entre ce que tu dis et le problème de Cloudflare décrit ici.

Ce problème à la base est dans un logiciel développé chez eux. Ils n'ont pas fait de tests dans le cas d'une valeur parmi 4 valeurs possibles de leurs "actions".

C'est le B.A BA du test unitaire de tester pour les 4 valeurs et de se rendre compte lors du test qu'il y a un problème pour la valeur execute si l'on veut activer le kill switch de leur firewall applicatif avec cette valeur execute.

Ce n'est pas en prod que l'on doit se rendre compte de ce genre de problème. C'est un problème laissé par un développeur.

Il n'y a aucune standardisation à attendre dans un logiciel propriétaire développé pour offrir un service très spécifique de protection aux clients de Cloudflare.

Derrière la récente panne Cloudflare, une mesure de protection contre la faille React

  • Protection lourde

  • Cloudflare se concentre sur les correctifs

Fermer