Cloudflare Gateway exécute désormais votre code en ligne pour une logique de sécurité personnalisée

Cloudflare a annoncé une expansion majeure de sa plateforme Zero Trust, permettant aux développeurs d'exécuter du code personnalisé directement dans le chemin d'évaluation des politiques de passerelle web sécurisée. Publiée le 15 octobre 2026, cette mise à jour intègre Cloudflare Workers aux services Gateway et Data Loss Prevention (DLP), autorisant l'exécution de logique arbitraire en ligne à la périphérie du réseau.

Ce qui s'est passé

Pendant des décennies, les passerelles web sécurisées ont fonctionné selon un modèle rigide : le trafic correspond à une condition prédéfinie, et le système exécute une action terminale telle que autoriser, bloquer ou journaliser. Bien qu'efficace pour les cas d'utilisation standard, cette approche peine à répondre aux exigences complexes et spécifiques à l'environnement. Les équipes de sécurité sont souvent confrontées à un choix binaire entre maintenir une infrastructure proxy personnalisée coûteuse pour une flexibilité maximale ou accepter les contraintes du fournisseur qui limitent leur capacité à résoudre des problèmes uniques.

Pour remédier à cela, Cloudflare introduit deux nouvelles capacités : l'action Forward et les Custom Functions. L'action Forward, disponible aujourd'hui en bêta publique, route les requêtes HTTP correspondantes vers un Cloudflare Worker, qui agit comme middleware en ligne. Cela permet aux développeurs de modifier les en-têtes, de transformer les corps de requête ou de déclencher des actions asynchrones telles que la journalisation vers des systèmes externes avant que le trafic n'atteigne sa destination. Les Custom Functions, dont la sortie est prévue avant la fin de l'année, permettront aux Workers de retourner des valeurs typées lors de l'évaluation des politiques, créant ainsi efficacement des sélecteurs dynamiques basés sur des données internes ou une logique complexe.

Cette intégration s'appuie sur l'infrastructure existante de Cloudflare, où Gateway et Workers s'exécutent sur les mêmes machines dans plus de 330 emplacements mondiaux. Comme la distribution est un appel de fonction local plutôt qu'un saut réseau, il n'y a pas de latence supplémentaire due au détour du trafic vers un environnement cloud séparé. Cette architecture vise à fournir la personnalisation des proxies auto-hébergés sans la charge opérationnelle liée à la gestion de l'infrastructure.

Comment cela fonctionne

L'action Forward transforme un Cloudflare Worker en proxy programmable. Lorsqu'une politique Gateway correspond à une requête, elle transmet le contexte HTTP complet — y compris les en-têtes et le corps — au Worker spécifié. Le Worker peut inspecter la requête, la modifier, puis la transmettre en amont en utilisant la fonction next(). Il peut également modifier la réponse avant son retour à l'utilisateur. Gateway gère les connexions TCP sous-jacentes, la terminaison TLS et la gestion des certificats, tandis que le Worker se concentre uniquement sur la logique au niveau de l'application.

Les Custom Functions fonctionnent différemment en s'intégrant directement dans le moteur de décision des politiques. Un Worker reçoit un contexte tel que l'IP source, l'identité de l'utilisateur et la posture de l'appareil, puis retourne une simple chaîne de caractères, un nombre ou un booléen. Cette valeur de retour devient un nouveau sélecteur dans le constructeur de politiques Gateway. Par exemple, une fonction pourrait analyser un JSON Web Token pour extraire le rôle d'un utilisateur et le retourner sous forme de chaîne. Les administrateurs peuvent ensuite écrire des règles comme "Autoriser si Custom Function Role equals finance_contractor", combinant des sélecteurs intégrés avec des données calculées personnalisées.

Détails clés

• Action Forward : Route le trafic HTTP correspondant vers un Worker pour une transformation en ligne, disponible en bêta publique à partir du 15 octobre 2026.
• Custom Functions : Permet aux Workers de retourner des valeurs typées pour utilisation dans les conditions de politique, lancement prévu avant la fin de 2026.
• Aucune surcharge de latence : La distribution vers un Worker est un appel de fonction local sur la même machine, évitant les allers-retours réseau.
• Disponibilité universelle : Les deux fonctionnalités seront disponibles sur tous les plans Zero Trust, y compris les niveaux Free, Paid et Enterprise.
• Facturation : Le trafic distribué aux Workers est facturé comme des requêtes Worker standard, soumis aux limites existantes de temps d'exécution et de requêtes quotidiennes.
• Sécurité de repli : Les Custom Functions nécessitent des valeurs par défaut pour garantir un comportement déterministe en cas d'échec ou de dépassement de délai du code.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables de la sécurité, ce changement élimine la nécessité de déployer et de maintenir des proxies NGINX séparés ou des pipelines de webhook complexes pour des transformations mineures du trafic. Les tâches qui nécessitaient auparavant la mise en place d'une infrastructure dédiée — telles que l'injection d'en-têtes HTTP basée sur des revendications JWT ou la création de pistes d'audit pour les accès sensibles — peuvent désormais être gérées avec quelques lignes de TypeScript dans un Worker. Cela réduit la dette opérationnelle et accélère la mise en œuvre de politiques de sécurité spécifiques aux outils et workflows internes d'une organisation.

La capacité d'exécuter du code arbitraire en ligne améliore également la réactivité en temps réel. Au lieu de dépendre de journaux retardés envoyés à un SIEM pour l'alerting, une action Forward peut déclencher des notifications immédiates vers Slack ou PagerDuty lorsqu'une règle DLP est activée. De plus, les Custom Functions permettent des contrôles d'accès plus nuancés en intégrant des sources de données externes, telles que des systèmes internes de notation des risques, directement dans le processus de prise de décision du pare-feu sans exposer ces systèmes à Internet public.

Ce que vous pouvez faire

• Évaluez la bêta publique de l'action Forward pour tester l'injection d'en-têtes en ligne ou la modification de requêtes pour vos applications internes.
• Identifiez les tâches de proxy manuelles actuelles, telles que l'analyse JWT ou la journalisation personnalisée, qui pourraient être migrées vers Cloudflare Workers.
• Concevez des Custom Functions qui s'intègrent aux bases de données ou API internes pour créer des sélecteurs de politiques dynamiques basés sur le contexte utilisateur en temps réel.
• Examinez vos politiques DLP existantes pour déterminer où une logique de validation personnalisée pourrait réduire les faux positifs en vérifiant la pertinence des données par rapport aux enregistrements internes.
• Surveillez les limites d'exécution et les coûts des Workers, surtout si vous prévoyez de router un trafic volumineux via les actions Forward.
• Préparez-vous à la sortie de fin d'année des Custom Functions en cartographiant la logique d'évaluation complexe qui nécessite actuellement un post-traitement externe.