Summary

  • draft-ietf-httpapi-privacy-06 says authenticated API clients should not rely on an HTTP-to-HTTPS redirect: the credential can leave in the initial cleartext request before the server has any opportunity to respond.
  • HSTS, HTTPS DNS records, a closed port 80, secure-context credential restrictions and fail-closed client defaults act at different moments. None can be replaced by a final HTTPS URL or a successful response.
  • When a credential reaches insecure HTTP, uniform rejection, exposure classification and revocation are separate decisions. The draft was IESG-approved and entered the RFC Editor Queue on 5 June 2026, but was still an Internet-Draft—not a published RFC—on 1 October.

The bug can survive precisely because the system works.

A developer configures the HTTP form of an API base address instead of its HTTPS form. The client constructs an authenticated request and opens a cleartext connection. It serializes an API key, bearer token or cookie into that request. The server replies with a redirect. The client follows it, negotiates TLS, sends another request and receives the expected object. The integration test passes. The first credential-bearing packet remains outside the protection of the connection that came later.

That is the hard temporal boundary in revision 06 of Protecting Credentials with HTTP APIs. A redirect is a response. It cannot exist until after a request has gone somewhere. If the request already contained reusable authority, the secure second exchange is not a repair of the first. It is a new exchange after disclosure.

Success is what hides the defect

Redirects are valuable on the human web. A person types a bare hostname, a browser initially tries HTTP, and the site guides the browser to HTTPS. For a credential-bearing API call, the usability bargain changes. Software does not need a forgiving bridge from a mistyped scheme; it needs an early, visible failure before secret material is serialized into an insecure transport.

The May 2024 field note that motivated the draft began with exactly this kind of typo. Its historical spot check found many API endpoints that redirected or otherwise answered HTTP. Those named observations are not a 2026 deployment census—some providers changed behavior, and an invalid test token does not prove every authenticated path. The durable evidence is the mechanism: a working redirect can make the insecure origin disappear from ordinary success metrics.

The final URL therefore proves too little. So does a 200 response. So does a TLS handshake on the second connection. The useful receipt chain looks different:

Receipt What it can establish What it cannot recover
Configured URI The scheme and endpoint supplied to the client Which transport the runtime actually opened
Pre-connection policy HSTS state, HTTPS RR result and client security mode A secret already sent before those controls applied
First wire request Actual scheme, peer and whether credential bytes entered cleartext Whether a later retry is secure
First response Redirect, rejection or other server behavior Confidentiality of the request that caused it
HTTPS retry TLS peer, protected request and response Erasure of the earlier network observation
Exposure decision Which credential class may have leaked Whether the credential has been revoked everywhere
Authorization and commit What the secure request was allowed to do and whether it committed Whether an observer reused the earlier credential elsewhere

One green secure=true flag cannot honestly represent this table.

Protection must act before the first request

The draft assembles several controls whose positions in time matter.

HTTP Strict Transport Security allows a host to tell a conforming client, over a secure connection, to use secure transport in the future. That is useful state. It also has a first-contact boundary and depends on the client persisting and applying the policy. An API client without browser-like HSTS storage cannot be credited with protection merely because the server emits the header.

HTTPS resource records can tell a client at connection time about a secure service. They move evidence earlier than an HTTP response. Yet a new client still needs DNS resolution and a policy for authenticated interpretation; an attacker controlling the path or resolver may suppress information. The draft recommends HSTS and HTTPS records together for authenticated endpoints while explicitly declining to call either foolproof.

The cleanest authentic-server posture is often simpler: do not accept unencrypted API connections. A closed port 80 means the real server cannot receive a credential over that channel. But the distinction between passive and active attack must remain visible. Refusal by the authentic server prevents delivery to that server; it does not stop an on-path attacker from impersonating an HTTP endpoint and accepting the client's connection. The decisive client-side rule is still to avoid sending the secret.

Credential objects can also constrain their own use. A Cookie with the Secure attribute is governed by RFC 6265 and must not be sent over an insecure channel. RFC 8959 defines a secret-token URI form that can convey expected secure usage. These are valuable typed controls, not a universal property of every custom header. An arbitrary X-Api-Key value does not acquire transport policy because its name looks sensitive.

The minimum client rule is consequently stronger than “follow safe redirects.” If authentication is in use, insecure operation should require an explicit signal separate from the URI; absent that signal, the client should use HTTPS exclusively and must not put secret tokens in Authorization, Proxy-Authorization or similar fields over an insecure connection.

A 403 is an incident marker, not an undo operation

Some hosts cannot simply close port 80 because authenticated and unauthenticated resources share infrastructure. Revision 06 recommends that when a credential arrives over an insecure channel, the server return 403 regardless of whether the credential is valid.

The uniformity matters. RFC 9110 permits 403 for a refusal unrelated to credential sufficiency. If valid and invalid candidates receive distinguishable responses, timing or content can become a credential-checking oracle. The secure behavior is to refuse before treating the insecure request as a normal authentication attempt.

But 403 does not make the credential secret again. It marks a transition from request handling to incident handling. The server still needs to classify what crossed the channel.

A directly transmitted API key or bearer token is reusable authority in the attacker's hands and should be treated as potentially compromised. A digital signature or MAC derived from a secret may expose only a per-message value, not the underlying credential; replay properties, nonce coverage and request binding then determine the response. “Authenticated request” is not one credential class, and revocation should not be decided by status code alone.

Immediate revocation has a counter-risk. An attacker can submit guessed candidate credentials over HTTP in the hope that the server will revoke a real one. The draft therefore makes denial-of-service control part of the same operating surface: connection limits, rate limits, notification and sometimes a grace process. That does not justify preserving an exposed bearer secret indefinitely. It means exposure evidence and revocation authority require their own auditable policy.

The server cannot own the whole invariant

It is tempting to make this a server-hardening story. That would miss the active-attacker case and the institutional split.

The client owns the last safe moment before transmission: scheme validation, HSTS or HTTPS RR use, explicit insecure-mode policy, redirect policy and credential attachment. The DNS operator owns availability and authenticity of discovery data. The network may observe or alter cleartext. The front end owns listening behavior and rejection. The credential issuer owns quarantine or revocation. The resource server owns authorization. The application owns whether a business action commits. Each actor can produce evidence for its stage; none can issue a receipt on behalf of all the others.

This is also why RFC 7258 matters beyond credentials. Pervasive monitoring is treated as an attack, so HTTPS is not merely a wrapper for tokens. Even an unauthenticated request can reveal paths, identifiers and operational intent. Credentials make the consequence sharper because observation can become reusable authority.

Approval is not deployment

The document's status deserves exact language. The Datatracker record identifies a HTTPAPI working-group document intended for Best Current Practice. Its history records IESG approval and movement to the RFC Editor Queue on 5 June 2026. The source remains revision 06, dated 11 May, and as of 1 October is still an Internet-Draft. It has not yet acquired an RFC number.

That institutional path is meaningful review evidence. The shepherd write-up records broad working-group agreement, HTTP and security review, and no submitted implementation reports. It does not establish that a particular SDK honors HSTS, queries HTTPS records, refuses cleartext credentials, distinguishes bearer material from derived authenticators or revokes exposed keys. The working repository shows document development; it is not a conformance catalogue.

This distinction is operationally useful. A policy team can adopt the guidance before publication. An auditor can test it after publication. Neither should write “BCP-compliant” into an asset inventory without observing the actual first request.

The wire-order ledger

For every authenticated API client, retain a testable record of the exact configured base URI; library and version; redirect mode; credential-attachment rule; explicit insecure-mode setting; DNS response and HTTPS RR result; HSTS state source, age and persistence outcome; actual first scheme, address, port and peer; whether a credential-bearing header or cookie was serialized; credential class without recording the secret; first response status and location; second connection's TLS version and authenticated peer; exposure classification; quarantine, rotation or revocation action; local authorization decision; commit identifier; and

independently observed effect.

Absence must remain absence. Record hsts_state=none, not secure_by_default, when the client implements no store. Record https_rr=suppressed_or_unavailable, not not_needed, when DNS evidence is missing. Record credential_exposure=possible even if the redirected request later succeeded. Record revocation=pending instead of converting a queued action into a completed control.

Minimum Initial Specification supports a thin invariant here: a shared API stack needs a deterministic rule against sending reusable secrets over insecure transport, not a sprawling central policy for every credential. Running-Code Primacy directs attention to the first bytes actually emitted rather than the URL shown at the end. The Policy Mirror reveals that SDK defaults and gateway listeners allocate real authority. Reality Layers keeps configuration, discovery, transport, exposure, response, retry, authorization and effect from collapsing into one successful request.

Sources