Clôture des ports HTTP sur api.cloudflare.com pour appliquer les connexions HTTPS uniquement

Les connexions établies sur les ports HTTP ClearText risquent d'exposer des informations sensibles car les données sont transmises non cryptées et peuvent être interceptées par les intermédiaires de réseau

Connections made over cleartext HTTP ports risk exposing sensitive information because the data is transmitted unencrypted and can be intercepted by network intermediaries, such as ISPs, Wi-Fi hotspot providers, or malicious actors on the same network. It’s common for servers to either redirect or return a 403 (Forbidden) response to close the HTTP connection and enforce the use of HTTPS by clients. However, by the time this occurs, it may be too late, because sensitive information, such as an API token, may have already been transmitted in cleartext in the initial client request. This data is exposed before the server has a chance to redirect the client or reject the connection.

Les connexions établies sur des ports HTTP en texte clair risquent d'exposer des informations sensibles car les données sont transmises non cryptées et peuvent être interceptées par des intermédiaires de réseau, tels que les FAI, les fournisseurs de points d'accès Wi-Fi ou les acteurs malveillants sur le même réseau. Il est courant que les serveurs redirigent ou renvoient une réponse 403 (interdite) pour fermer la connexion HTTP et appliquer l'utilisation de HTTPS par les clients. Cependant, au moment où cela se produit, il peut être trop tard, car des informations sensibles, telles qu'un jeton API, ont peut-être déjà été transmise dans ClearText dans la demande du client initial. Ces données sont exposées avant que le serveur ait la possibilité de rediriger le client ou de rejeter la connexion.

A better approach is to refuse the underlying cleartext connection by closing the network ports used for plaintext HTTP, and that’s exactly what we’re going to do for our customers.

Une meilleure approche consiste à refuser la connexion ClearText sous-jacente en fermant les ports réseau utilisés pour le texte clair HTTP, et c'est exactement ce que nous allons faire pour nos clients.

Today we’re announcing that we’re closing all of the HTTP ports on api.cloudflare.com. We’re also making changes so that api.cloudflare.com can change IP addresses dynamically, in line with on-going efforts to decouple names from IP addresses, and reliably managing addresses in our authoritative DNS. This will enhance the agility and flexibility of our API endpoint management. Customers relying on static IP addresses for our API endpoints will be notified in advance to prevent any potential availability issues.

Aujourd'hui, nous annonçons que nous fermons tous les ports HTTP sur api.cloudflare.com. Nous apportons également des modifications afin que API.cloudflare.com puisse modifier les adresses IP dynamiquement, conformément aux efforts en cours pour découpler les noms à partir d'adresses IP et gérer de manière fiable les adresses dans notre DNS faisant autorité. Cela améliorera l'agilité et la flexibilité de notre gestion des points de terminaison API. Les clients qui s'appuient sur des adresses IP statiques pour nos points de terminaison de l'API seront informés à l'avance pour éviter tout problème de disponibilité potentiel.

In addition to taking this first step to secure Cloudflare API traffic, we’ll release the ability for customers to opt-in to safely disabling all HTTP port traffic for their websites on Cloudflare. We expect to make this free security feature available in the last quarter of 2025.

En plus de faire cette première étape pour sécuriser le trafic API CloudFlare, nous publierons la possibilité pour les clients de s'opposer à désactiver en toute sécurité tout le trafic portuaire HTTP pour leurs sites Web sur CloudFlare. Nous nous attendons à rendre cette fonction de sécurité gratuite disponible au dernier trimestre de 2025.

We have consistently advocated for strong encryption standards to safeguard users’ data and privacy online. As part of our ongoing commitment to enhancing Internet security, this blog post details our efforts to enforce HTTPS-only connections across our global network.

Nous avons toujours plaidé pour des normes de chiffrement solides pour protéger les données et la confidentialité des utilisateurs en ligne. Dans le cadre de notre engagement continu à améliorer la sécurité Internet, ce billet de blog détaille nos efforts pour appliquer les connexions HTTPS uniquement sur notre réseau mondial.

Understanding the problem

Comprendre le problème

We already provide an “Always Use HTTPS” setting that can be used to redirect all visitor traffic on our customers’ domains (and subdomains) from HTTP (plaintext) to HTTPS (encrypted). For instance, when a user clicks on an HTTP version of the URL on the site (http://www.example.com), we issue an HTTP 3XX redirection status code to immediately redirect the request to the corresponding HTTPS version (https://www.example.com) of the page. While this works well for most scenarios, there’s a subtle but important risk factor: What happens if the initial plaintext HTTP request (before the redirection) contains sensitive user information?

Nous fournissons déjà un paramètre «Utilisez toujours HTTPS» qui peut être utilisé pour rediriger tout le trafic des visiteurs sur les domaines (et sous-domaines) de nos clients de HTTP (PlainText) vers HTTPS (crypté). Par exemple, lorsqu'un utilisateur clique sur une version HTTP de l'URL sur le site (http://www.example.com), nous émettons un code d'état de redirection HTTP 3XX pour rediriger immédiatement la demande vers la version HTTPS correspondante (https://www.example.com) de la page. Bien que cela fonctionne bien pour la plupart des scénarios, il y a un facteur de risque subtil mais important: que se passe-t-il si la demande HTTP initiale en texte clair (avant la redirection) contient des informations utilisateur sensibles?

Initial plaintext HTTP request is exposed to the network before the server can redirect to the secure HTTPS connection.

La demande HTTP initiale en clair est exposée au réseau avant que le serveur ne puisse rediriger vers la connexion HTTPS sécurisée.

Third parties or intermediaries on shared networks could intercept sensitive data from the first plaintext HTTP request, or even carry out a Monster-in-the-Middle (MITM) attack by impersonating the web server.

Des tiers ou des intermédiaires sur les réseaux partagés pourraient intercepter les données sensibles de la première demande HTTP en texte en clair, ou même effectuer une attaque de monstre dans le milieu (MITM) en usurpant l'identité du serveur Web.

One may ask if HTTP Strict Transport Security (HSTS) would partially alleviate this concern by ensuring that, after the first request, visitors can only access the website over HTTPS without needing a redirect. While this does reduce the window of opportunity for an adversary, the first request still remains exposed. Additionally, HSTS is not applicable by default for most non-user-facing use cases, such as API traffic from stateless clients. Many API clients don’t retain browser-like state or remember HSTS headers they've encountered. It is quite common practice for API calls to be redirected from HTTP to HTTPS, and hence have their initial request exposed to the network.

On peut lui demander si HTTP Strict Transport Security (HSTS) atténuerait partiellement cette préoccupation en s'assurant qu'après la première demande, les visiteurs ne peuvent accéder au site Web que sur HTTPS sans avoir besoin d'une redirection. Bien que cela réduit la fenêtre d'opportunité d'un adversaire, la première demande reste exposée. De plus, HSTS n'est pas applicable par défaut pour la plupart des cas d'utilisation sans utilisateur, tels que le trafic API des clients sans état. De nombreux clients API ne conservent pas un état de navigateur ou se souviennent des en-têtes HSTS qu'ils ont rencontrés. Il est assez courant que les appels d'API soient redirigés de HTTP vers HTTPS, et donc leur demande initiale exposée au réseau.

Therefore, in line with our culture of dogfooding, we evaluated the accessibility of the Cloudflare API (api.cloudflare.com) over HTTP ports (80, and others). In that regard, imagine a client making an initial request to our API endpoint that includes their secret API key. While we outright reject all plaintext connections with a 403 Forbidden response instead of redirecting for API traffic — clearly indicating that “Cloudflare API is only accessible over TLS” — this rejection still happens at the application layer. By that point, the API key may have already been exposed over the network before we can even reject the request. We do have a notification mechanism in place to alert customers and rotate their API keys accordingly, but a stronger approach would be to eliminate the exposure entirely. We have an opportunity to improve!

Par conséquent, conformément à notre culture de chiens de dog, nous avons évalué l'accessibilité de l'API CloudFlare (api.cloudflare.com) sur les ports HTTP (80 et autres). À cet égard, imaginez un client faisant une demande initiale à notre point de terminaison de l'API qui inclut sa clé API secrète. Alors que nous rejetons carrément toutes les connexions en texte en clair avec une réponse interdite 403 au lieu de rediriger le trafic API - indiquant clairement que «l'API CloudFlare n'est accessible qu'au TLS» - ce rejet se produit toujours sur la couche d'application. À ce stade, la clé API peut avoir déjà été exposée sur le réseau avant même de rejeter la demande. Nous avons un mécanisme de notification en place pour alerter les clients et faire pivoter leurs clés API en conséquence, mais une approche plus forte consisterait à éliminer complètement l'exposition. Nous avons l'occasion de nous améliorer!

A better approach to API security

Une meilleure approche de la sécurité des API

Any API key or token exposed in plaintext on the public Internet should be considered compromised. We can either address exposure after it occurs or prevent it entirely. The reactive approach involves continuously tracking and revoking compromised credentials, requiring active management to rotate each one. For example, when a plaintext HTTP request is made to our API endpoints, we detect exposed tokens by scanning for 'Authorization' header values.

Toute clé API ou jeton exposé en texte clair sur Internet public doit être considéré comme compromis. Nous pouvons soit aborder l'exposition après qu'il se produise, soit l'empêcher entièrement. L'approche réactive consiste à suivre et à révoquer continuellement les références compromises, nécessitant une gestion active de faire pivoter chacun. Par exemple, lorsqu'une demande HTTP en texte clair est faite à nos points de terminaison API, nous détectons les jetons exposés en parcourant des valeurs d'en-tête «autorisation».

In contrast, a preventive approach is stronger and more effective, stopping exposure before it happens. Instead of relying on the API service application to react after receiving potentially sensitive cleartext data, we can preemptively refuse the underlying connection at the transport layer

En revanche, une approche préventive est plus forte et plus efficace, arrêtant l'exposition avant qu'elle ne se produise. Au lieu de s'appuyer sur l'application de service API pour réagir après avoir reçu des données ClearText potentiellement sensibles, nous pouvons refuser de manière préventive la connexion sous-jacente à la couche de transport