api.cloudflare.comでHTTPポートを閉じて、HTTPSのみの接続を実施します

データが暗号化されずに送信され、ネットワーク仲介業者によって傍受されるため、Cleartextに作られたHTTPポートが機密情報を公開するリスクがあります

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.

Cleartext httpポートを介して行われた接続は、データが暗号化されていないために送信され、ISP、Wi-Fiホットスポットプロバイダー、同じネットワーク上の悪意のあるアクターなどのネットワーク仲介者が傍受できるため、機密情報の公開リスクがあります。サーバーは、HTTP接続を閉じてクライアントによるHTTPSの使用を実施するために、403（禁止）応答をリダイレクトまたは返すことが一般的です。ただし、これが発生するまでに、APIトークンなどの機密情報が最初のクライアントリクエストで既にクリアテキストに送信されている可能性があるため、遅すぎる可能性があります。このデータは、サーバーがクライアントをリダイレクトしたり、接続を拒否する機会がある前に公開されます。

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.

より良いアプローチは、Plantext HTTPに使用されるネットワークポートを閉じることにより、基礎となるClearText接続を拒否することです。それがまさにお客様のためにやろうとしていることです。

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.

本日、api.cloudflare.comのすべてのHTTPポートを閉鎖することを発表しています。また、API.Cloudflare.comがIPアドレスを動的に変更できるように変更を行っています。IPアドレスから名前を切り離すための継続的な取り組みに沿って、権威あるDNSのアドレスを確実に管理しています。これにより、APIエンドポイント管理の俊敏性と柔軟性が向上します。 APIエンドポイントの静的IPアドレスに依存する顧客には、潜在的な可用性の問題を防ぐために事前に通知されます。

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.

CloudFlare APIトラフィックを保護するためのこの最初のステップを踏むことに加えて、CloudFlareのWebサイトのすべてのHTTPポートトラフィックを安全に無効にするために、顧客がオプトインする機能をリリースします。この無料のセキュリティ機能を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.

ユーザーのデータとプライバシーをオンラインで保護するための強力な暗号化基準を一貫して提唱しています。インターネットセキュリティを強化するという継続的なコミットメントの一環として、このブログ投稿では、グローバルネットワーク全体でHTTPSのみの接続を実施する努力について詳しく説明しています。

Understanding the problem

問題を理解する

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?

すでに「常に使用する」設定を提供しています。これは、顧客のドメイン（およびサブドメイン）のすべての訪問者トラフィックをHTTP（プレーンテキスト）からHTTPS（暗号化）にリダイレクトするために使用できます。たとえば、ユーザーがサイト上のURLのHTTPバージョン（http://www.example.com）をクリックすると、HTTP 3XXリダイレクトステータスコードを発行して、リクエストを対応するHTTPSバージョン（https://www.example.com）に直接リダイレクトします。これはほとんどのシナリオではうまく機能しますが、微妙だが重要なリスク要因があります。初期のプレーンテキストHTTP要求（リダイレクトの前）に機密のユーザー情報が含まれている場合はどうなりますか？

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

初期プレーンテキストHTTP要求は、サーバーがセキュアHTTPS接続にリダイレクトできる前にネットワークに公開されます。

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.

共有ネットワークの第三者または仲介者は、最初のプレーンテキストHTTPリクエストから機密データを傍受したり、Webサーバーになりすましてモンスターインザミドル（MITM）攻撃を実行することもできます。

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.

HTTP Strict Transport Security（HSTS）が、最初のリクエストの後、訪問者がリダイレクトを必要とせずにHTTPSを介してWebサイトにのみアクセスできるようにすることにより、この懸念を部分的に緩和するかどうかを尋ねることができます。これは敵の機会の窓を減らしますが、最初の要求はまだ暴露されたままです。さらに、HSTSは、ステートレスクライアントからのAPIトラフィックなど、ほとんどの非ユーザー向けのユースケースにデフォルトでは適用されません。多くのAPIクライアントは、ブラウザのような状態を保持していないか、遭遇したHSTSヘッダーを覚えていません。 API呼び出しがHTTPからHTTPSにリダイレクトされることは非常に一般的な慣行であり、したがって、最初の要求をネットワークにさらします。

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!

したがって、DogFoodingの文化に沿って、HTTPポート（80など）を介したCloudFlare API（API.Cloudflare.com）のアクセシビリティを評価しました。その点で、クライアントがSecret APIキーを含むAPIエンドポイントに最初のリクエストを行うことを想像してください。 APIトラフィックをリダイレクトする代わりに、403の禁止された応答ですべてのプレーンテキスト接続を完全に拒否しますが、「CloudFlare APIはTLSでのみアクセスできる」ことを明確に示していますが、この拒否はアプリケーション層で発生します。その時点までに、リクエストを拒否する前に、APIキーはすでにネットワーク上で公開されている可能性があります。顧客に警告し、それに応じてAPIキーを回転させるための通知メカニズムがありますが、より強力なアプローチは、露出を完全に排除することです。改善する機会があります！

A better approach to API security

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.

パブリックインターネット上のプレーンテキストに露出したAPIキーまたはトークンは、妥協したと見なされる必要があります。曝露が発生した後に曝露に対処するか、完全に防ぐことができます。反応的なアプローチには、侵害された資格情報を継続的に追跡して取り消すことが含まれ、それぞれを回転させるためにアクティブな管理が必要です。たとえば、APIエンドポイントに対してPlantext HTTP要求が行われると、「承認」ヘッダー値をスキャンして露出したトークンを検出します。

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

対照的に、予防的アプローチはより強く、より効果的であり、それが起こる前に暴露を停止します。潜在的に機密性の高いクリアテキストデータを受信した後にAPIサービスアプリケーションに依存して反応する代わりに、輸送層で基礎となる接続を先制的に拒否できます