Cloudflare rend la sécurité web programmable avec Workers

CCloudflare rapproche sa passerelle web sécurisée de sa plateforme de développement Workers. Avec Forward, disponible en bêta publique, les entreprises peuvent ajouter du code au traitement de certaines requêtes HTTP autorisées.[2] Pour les équipes IT, cette évolution ouvre une possibilité concrète : adapter les contrôles aux usages métier. Elle impose aussi de traiter ce code comme un composant sensible, dont une erreur peut perturber le travail des utilisateurs.

La passerelle devient un point de personnalisation

Une passerelle web sécurisée contrôle les accès des utilisateurs aux services web. Son rôle diffère de celui d’un WAF, généralement placé devant une application pour la protéger. Le sujet concerne ici les flux qui traversent Cloudflare Gateway et les traitements que l’entreprise souhaite leur appliquer.

Le Worker peut modifier une requête ou une réponse, produire sa propre réponse ou lancer une tâche en arrière-plan. Gateway conserve la gestion de la connexion proxy, du déchiffrement TLS et du routage vers le service.[2] L’entreprise apporte donc une logique applicative à un chemin réseau déjà administré.

Cette souplesse peut intéresser une équipe qui doit appliquer une exception précise à un outil métier. Mais le besoin doit être clairement défini : ajouter du code augmente aussi le nombre de comportements à comprendre en cas d’incident.

Deux mécanismes avec des calendriers différents

L’annonce du 15 octobre distingue Forward et les Custom Functions. Ces dernières sont attendues avant la fin de 2026 : elles doivent retourner une valeur utilisable dans les conditions d’une politique Gateway, à partir d’une logique propre à l’organisation.[1] Leur calendrier ne doit pas être confondu avec la bêta déjà accessible.

Cloudflare illustre cette approche par des pages demandant une justification d’accès, des transformations d’en-têtes et des notifications. Les appels aux Workers suivent leur tarification habituelle, avec les quotas et limites d’exécution associés à l’offre choisie.[1] La personnalisation doit donc être évaluée avec son coût d’exploitation.

Trois questions pour choisir le bon contrôle

Cette grille propose des critères de décision pour un pilote, sans présumer de gains mesurés en production.

Le code reste soumis au périmètre de la passerelle

La documentation précise que Forward ne contourne pas une règle de blocage. L’inspection peut interrompre le Worker, et le trafic WebSocket rejoint directement le service d’origine sans passer par celui-ci.[2] La présence d’un Worker ne démontre donc pas que tous les échanges d’une application sont couverts.

L’annonce indique que Gateway et Workers partagent la même infrastructure, ce qui évite un saut réseau pour leur liaison.[1] Cela ne supprime pas le temps d’exécution du code ni celui des éventuels services externes appelés. Une dépendance lente peut affecter l’expérience utilisateur : il faut mesurer le parcours complet.

Une PME peut commencer par un seul usage métier

Prenons un scénario illustratif : une PME souhaite afficher un rappel avant l’accès à un service de partage de fichiers. Un pilote pourrait viser un domaine et un petit groupe de test. L’équipe vérifierait que le rappel apparaît au bon moment, que les connexions restent possibles et que les échanges non concernés continuent normalement.

Les essais devraient inclure une requête habituelle, un format inattendu et une indisponibilité du service éventuellement appelé. Il faudrait comparer les délais, examiner les journaux et préparer le retour à la configuration précédente. Ce scénario est une proposition de test, pas un déploiement client rapporté par Cloudflare.

Le professionnel conçoit et maintient des contrôles vérifiables

Cette évolution mobilise directement la Cybersécurité. Le professionnel doit traduire une exigence métier en comportement précis : quel flux contrôler, quelle information utiliser, quelle action autoriser et quelle trace conserver. Une règle doit pouvoir être expliquée à ceux qu’elle protège comme à ceux qui la maintiennent.

Le travail comprend désormais la revue du code et de ses dépendances. Les permissions, les secrets et les données inscrites dans les journaux méritent une attention particulière. Les tests doivent vérifier aussi bien le blocage attendu que la continuité des usages légitimes.

La maintenance se poursuit après le déploiement. Une évolution d’application ou d’identité peut rendre une hypothèse incorrecte. Versionner les changements, désigner un responsable et conserver une procédure de retrait permettent de garder la maîtrise du contrôle dans la durée.

Repère éditorial

Une passerelle programmable donne davantage de latitude aux équipes capables de maintenir leurs extensions. Pour une petite structure, le bon critère reste le besoin résolu : la personnalisation apporte-t-elle un contrôle utile et vérifiable, avec une charge de maintenance acceptable ?

L’Actu IT à 360°, décrypter la technologie pour comprendre les métiers de demain.

Découvrir CCCLX →