Zusammenfassung

  • draft-ietf-httpapi-privacy-06 setzt die Sicherheitsgrenze vor die 3xx-Antwort: Ein authentifizierter API-Client kann Schlüssel, Cookie oder Bearer-Token bereits in der ersten HTTP-Anfrage senden.
  • HSTS, DNS-HTTPS-Record, geschlossener Port 80, sichere Nutzungsvorgabe des Zugangsmittels und HTTPS-only-Standard des Clients wirken an unterschiedlichen Stellen. Die letzte URL ist kein Nachweis für die erste Übertragung.
  • Trifft ein Zugangsmittel unverschlüsselt ein, folgen ein einheitliches Verbot, eine Expositionsbewertung und gegebenenfalls Widerruf. Der Entwurf ist vom IESG gebilligt und in der RFC Editor Queue, war am 1. Oktober 2026 aber noch kein RFC.

Der gefährlichste Konfigurationsfehler ist nicht immer derjenige, der den Dienst anhält. Manchmal sorgt eine automatische Korrektur dafür, dass er jahrelang funktioniert.

Steht in der API-Basisadresse http://, baut die Bibliothek dennoch die authentifizierte Anfrage, hängt das Token an und sendet sie. Der Server antwortet mit einer Umleitung. Der Client folgt, verhandelt TLS und erhält die erwarteten Daten. Funktional ist alles gelungen; zeitlich kam die Verschlüsselung zu spät.

Revision 06 von Protecting Credentials with HTTP APIs trennt diese beiden Tatsachen. Eine Umleitung ist eine Antwort und kann erst entstehen, nachdem eine Anfrage einen Empfänger erreicht hat. Der zweite Kanal schützt nicht rückwirkend den ersten.

Die grüne Messung verdeckt den falschen Anfang

Bei einer menschlich bedienten Webseite ist der Weg von HTTP zu HTTPS oft eine sinnvolle Brücke. Ein API-Client kennt dagegen eine vollständige URI und besitzt wiederverwendbare Befugnis. Er braucht keine stillschweigende Reparatur, sondern einen sichtbaren Fehler, bevor das Geheimnis serialisiert wird.

Der Feldbericht vom Mai 2024, der die Arbeit auslöste, begann mit genau einem solchen Tippfehler und prüfte damalige Dienste. Die einzelnen Anbietergebnisse sind eine historische Momentaufnahme, kein aktueller Verbreitungsnachweis. Der Mechanismus bleibt: Erfolgsmetriken können eine erste Klartextübertragung unsichtbar machen.

Darum müssen Absicht, Entdeckung, erste Verbindung, Antwort, Wiederholung, Widerruf und Wirkung getrennt bleiben. Die konfigurierte URI sagt nicht, welchen Socket die Laufzeit öffnete. Ein finaler TLS-Handshake sagt nichts über vorher gesendete Bytes. Ein 200 beweist weder Geheimhaltung noch erfolgten Widerruf.

Schutz muss vor dem ersten Byte greifen

HSTS nach RFC 6797 lässt einen Host künftige sichere Verbindungen verlangen. Der Client lernt diese Vorgabe über eine frühere sichere Verbindung und muss sie speichern. Ein Server-Header allein stattet ein API-SDK nicht mit einem Browser-Zustandsspeicher aus.

Der HTTPS Resource Record aus RFC 9460 bringt Information vor die Verbindung. Der Client muss ihn jedoch abfragen und auswerten; bei einem neuen Client kann ein Beherrscher von Pfad oder DNS die Antwort unterdrücken. Beide Mechanismen zusammen sind Schichten, keine rückwirkende Garantie.

Nimmt der echte Server auf Port 80 nichts an, kann er dort auch kein Geheimnis empfangen. Ein aktiver Angreifer kann sich trotzdem als fehlender HTTP-Endpunkt ausgeben. Deshalb bleibt die letzte unverzichtbare Regel im Client: kein Geheimnis anhängen, bevor sicherer Transport gewählt ist.

Auch das Zugangsmittel kann eine Einschränkung tragen. Secure nach RFC 6265 hält Cookies aus unsicheren Kontexten heraus. Das secret-token-Schema aus RFC 8959 kann die erwartete Nutzung mitteilen. Ein proprietärer Header vollstreckt seine Sensibilität nicht durch seinen Namen.

403 kennzeichnet den Vorfall

Muss HTTP verfügbar bleiben, empfiehlt der Entwurf für jede unsichere Anfrage mit Zugangsmittel denselben Status 403, unabhängig von dessen Gültigkeit. RFC 9110 lässt eine solche Verweigerung aus einem Grund zu, der nicht die Eignung der Zugangsdaten bewertet. Unterschiedliche Codes, Texte oder Zeiten würden einen Prüfdienst für geratenen Schlüsselwert schaffen.

Die Verweigerung macht das Zugangsmittel nicht wieder geheim. Direkt übertragener API-Key oder Bearer-Token ist kopierbare Befugnis und gilt als möglicherweise kompromittiert. Eine Signatur oder ein MAC kann nur einen abgeleiteten Wert offenlegen; dann sind Bindung, Nonce, Geltungsbereich und Wiederholung gesondert zu prüfen.

Sofortiger Widerruf kann selbst missbraucht werden. Ein Angreifer sendet viele geratenen Werte über HTTP und hofft, einen gültigen stillzulegen. Verbindungs- und Ratenlimits, Benachrichtigung, Quarantäne und kontrollierte Frist gehören daher zur Betriebsentscheidung. Sie ändern nicht die beobachtete Exposition.

Dokumentstatus ist kein Implementierungsstatus

Der Datatracker-Eintrag führt den HTTPAPI-Entwurf mit Ziel Best Current Practice. Die Historie vermerkt IESG-Zustimmung und Übergang in die RFC Editor Queue am 5. Juni 2026. Am 1. Oktober blieb die Quelle Revision 06 vom 11. Mai ohne RFC-Nummer.

Das ist belastbare Prüfgeschichte, aber kein Nachweis für eine konkrete Bibliothek. Im Shepherd-Material wurden keine speziellen Implementierungsberichte genannt. Das Arbeitsrepository zeigt Textentwicklung, nicht das erste Paket einer installierten SDK-Version.

RFC 7258 behandelt flächendeckende Überwachung als Angriff. Selbst ohne Token können Pfad, Kennung und Absicht sensibel sein. Mit Bearer-Token wird Beobachtung zur potenziellen Ausführungsbefugnis.

Ein Nachweisbuch in Leitungsreihenfolge

Zu speichern sind genaue Basis-URI, Bibliothek und Version, Umleitungsregel, Zeitpunkt des Anhängens, gesonderte Unsicher-Ausnahme, DNS- und HTTPS-RR-Ergebnis, Quelle und Alter des HSTS-Zustands, erstes tatsächliches Schema/Adresse/Port/Gegenüber, Zugangsmittelklasse ohne Geheimwert, erste Antwort und Location, TLS-Gegenüber der Wiederholung, Expositionsklasse, Quarantäne/Rotation/Widerruf und dessen Verteilung, Autorisierung, Commit-Kennung und beobachtete Wirkung.

Fehlendes bleibt fehlend: hsts=none, https_rr=unavailable, exposure=possible, revocation=pending. Der spätere HTTPS-Span darf den ersten HTTP-Versuch nicht überschreiben.

Die Minimum Initial Specification trägt hier eine schmale gemeinsame Regel: kein wiederverwendbares Geheimnis auf unsicherem Transport. Running-Code Primacy verlangt die tatsächlichen ersten Bytes. The Policy Mirror macht SDK-Defaults als Macht sichtbar. Reality Layers trennt Konfiguration, Entdeckung, Exposition, Antwort, Autorisierung und Wirkung.

Quellen