Closing the cleartext door on Cloudflare APIs
Cleartext HTTP connections leave sensitive data exposed to any network intermediary between client and server. Servers commonly respond to plaintext requests with a redirect or a 403 (Forbidden) status, but that enforcement happens only after the request — including any API token it carried — has already crossed the network unencrypted.
Cloudflare is taking a stronger stance for its own API endpoints: as of today, all HTTP ports on api.cloudflare.com are closed. Plaintext connections are refused at the transport layer, before any application data can be transmitted. The company is also preparing to let customers opt in to the same protection for their own domains, with the feature expected to be free and available in the last quarter of 2025.
Why redirects are not enough
Cloudflare's existing "Always Use HTTPS" setting works by issuing an HTTP 3XX redirect when a client requests the plaintext version of a URL. That covers most browser traffic, but it leaves a window of exposure: the initial HTTP request itself is visible before the redirect is sent.
HTTP Strict Transport Security (HSTS) narrows that window by telling browsers to use HTTPS for subsequent requests, but it does nothing for the first request. For API traffic, the gap is wider. Many API clients are stateless and do not retain HSTS policies, so it remains common practice for API calls to be redirected from HTTP to HTTPS — with the initial request, headers and all, exposed to the network.
Cloudflare already rejects plaintext API requests with a 403 response, making clear that the API is only accessible over TLS. That rejection, however, happens at the application layer. By the time the server evaluates the request, a secret API key in the Authorization header may already have been intercepted. The company has notification and rotation mechanisms for exposed keys, but preventing the exposure outright is the better fix.
Refusing the connection before the handshake
The preventive approach operates at the transport layer rather than the application layer. An HTTP request cannot begin until a TCP or QUIC connection is established, and that connection requires agreement on an IP address and port. Port 80 is the standard channel for plaintext HTTP; port 443 is for HTTPS. If the server simply does not listen for cleartext HTTP on a given IP, the transport handshake fails and no application data — not a single byte of a request — ever leaves the client.
This also gives developers a clear, fast-failure signal when they mistakenly point a client at http://… instead of https://… and include a secret key in the first request. The connection dies immediately, rather than after the key has been transmitted.
Why closing every HTTP port is hard
The straightforward version of this change — turn off port 80 everywhere — would break a substantial amount of legitimate traffic. Cloudflare Radar data shows that roughly 2–3% of requests from "likely human" clients arrive over plaintext HTTP. Among "likely automated" traffic, that share rises above 16%. IoT devices, legacy software stacks and automated API clients often lack the browser protections that silently upgrade or warn against insecure connections, and many still rely on plaintext.
A second obstacle is architectural. The longstanding BSD Sockets API forces operators to choose between scalability and flexibility when binding sockets to IP addresses and ports. Cloudflare has addressed that with Tubular, a tool that inspects every terminated connection and decides which application receives it. Tubular's "bindings" decouple sockets from specific IP:port pairs, allowing different IP addresses to be handled differently without sacrificing scale.
Implementation steps
The first step was provisioning IPv4 and IPv6 address space on which all HTTP ports are closed by default. Using Tubular, Cloudflare bound these anycast prefixes to its TLS-terminating proxies worldwide. Its global iptables firewall configuration was extended to reject any inbound packets destined for HTTP ports on those addresses.
iptables -A INPUT -p tcp -d <IP_ADDRESS_BLOCK> --dport <HTTP_PORT> -j REJECT
--reject-with tcp-reset
iptables -A INPUT -p udp -d <IP_ADDRESS_BLOCK> --dport <HTTP_PORT> -j REJECT
--reject-with icmp-port-unreachableWith the new IP space refusing plaintext at the transport layer, the next step was routing API traffic to it. Policy in the authoritative DNS server, expressed as a declarative Topaz program, now maps any DNS query in the "API traffic" class to the HTTPS-only interface addresses. Topaz's guarantees of exclusivity ensure no other DNS policy can accidentally match the same queries and route plaintext-expected domains to the HTTPS-only IPs.
api.cloudflare.com is the first domain in this HTTPS-only API traffic class. Other applicable endpoints will follow.
Opting in customer domains
Before extending the feature to customers, Cloudflare is monitoring side effects on its own API endpoints. The rollout across data centers was gradual, using Topaz to target subsets of traffic and minimize disruption.
Customers who want to assess the impact before opting in can review their dashboard under "Analytics & Logs" and look at the "Traffic Served Over SSL" section. That view provides a baseline of how much plaintext HTTP traffic currently reaches their site — traffic that would be blocked after opting in, dropping that number to zero.
The opt-in capability for customer domains, via dashboard or API, is expected in the last quarter of 2025. For api.cloudflare.com, the change is already effective: clients should no longer expect a 403 response to HTTP requests, because the connection itself will be refused.
Looking ahead
Cloudflare also plans to decouple api.cloudflare.com from static IP addresses, part of a broader effort toward addressing agility. That transition will include discontinuing support for non-SNI clients on the Cloudflare API. Currently, about 0.55% of TLS connections to the API lack a Server Name Indication value, and those connections come from a small number of accounts. Affected customers will be coordinated with before the change is made.
Beyond the API, Cloudflare is exploring other areas where closing plaintext ports is safe. The long tail of unencrypted traffic may persist, but it need not be accepted on every service.
