upgrade-insecure-requests: unsichere Anfragen vor dem Absenden auf HTTPS umleiten

upgrade-insecure-requests ist eine Content-Security-Policy-Direktive, die eine http://-URL in https:// umschreibt, bevor der Browser die Anfrage sendet. Ein Response-Header genügt, und alle http://-Subressourcen der Seite werden über https:// geladen. Es ist eine Umschreibung, keine Reparatur: Antwortet die sichere URL nicht, schlägt die Anfrage fehl, ohne Rückfall auf HTTP. HSTS ersetzt sie ebenfalls nicht, weil Links zu einem anderen Host unangetastet bleiben.

Was upgrade-insecure-requests ändert

Die Direktive greift früher als die Blockierung gemischter Inhalte. Die W3C-Spezifikation beschreibt, dass der Mechanismus a-priori-unsichere Ressourcenanfragen „before fetching them“ auf sicheren Transport hebt und dass die Umschreibung vor den Prüfungen für gemischte Inhalte und CSP stattfindet. Eine so gehobene Anfrage wird deshalb nicht als gemischter Inhalt gemeldet (Upgrade Insecure Requests, Candidate Recommendation vom 8. Oktober 2015, gelesen am 2026-11-03). MDN beschreibt dasselbe Verhalten und führt die Funktion seit April 2018 als Baseline weit verfügbar (MDN, gelesen am 2026-11-03).

Der ganze Wert liegt in diesem Zeitpunkt: Der Browser sendet die unsichere Anfrage gar nicht erst, also hat die Blockierung gemischter Inhalte nichts zu fangen.

Die vierte Zeile wird am häufigsten übersehen. Eine Navigation innerhalb derselben Site wird gehoben, eine Navigation zu einem anderen Host nicht (dieselbe Spezifikation, Abschnitt 1.2.2, gelesen am 2026-11-03). Deshalb ersetzt diese Direktive HSTS nicht.

upgrade-insecure-requests einbauen

Ein Response-Header reicht. Setze ihn auf jede HTML-Antwort, die eine unsichere URL enthalten kann.

Content-Security-Policy: upgrade-insecure-requests

Wenn der Hoster keine Header erlaubt, bleibt das meta-Element. Es deckt nur das Dokument ab, das es trägt.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Setze block-all-mixed-content nicht daneben. MDN führt diese Direktive als veraltet, und laut W3C-Spezifikation wird upgrade-insecure-requests zuerst ausgewertet, wodurch block-all-mixed-content bei beiden Angaben wirkungslos ist (MDN, gelesen am 2026-11-03). Nimm eine von beiden.

Unsichere URLs finden, bevor du erzwingst

Zähle zuerst. Die beiden Befehle unten dauern eine Minute und liefern eine Liste, über die du streiten kannst. Sie finden nicht alles: von JavaScript gebaute URLs und URLs in CSS erscheinen im zweiten Befehl nicht.

# 1. Sendet die Seite die Direktive bereits?
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. Welche Ressourcen laufen noch über http://?
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

Führe den zweiten Befehl auf den Templates aus, die die meisten Seiten erzeugen, nicht nur auf der Startseite. Checkout, Artikel und Landingpage laden oft unterschiedliche Drittanbieter. Wenn danach noch Warnungen zu gemischten Inhalten auftauchen, steht die Diagnose in gemischte Inhalte reparieren (auf Englisch).

Ein Deployment im Report-Only-Modus liefert die echte Liste. Der Browser sendet Verstoßberichte, ohne etwas umzuschreiben, sodass du sie mit dem Ergebnis deines Quellcode-Scans vergleichen kannst.

Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-reports

report-uri ist der ältere Mechanismus. report-to ist die neuere Endpunkt-Konfiguration, aber beide sind nicht bei jedem Hoster austauschbar. Wir haben die Berichtszustellung nicht bei jedem CDN getestet. Prüfe deshalb, ob an deinem Endpunkt etwas ankommt, bevor du einen leeren Bericht als Beweis für Abwesenheit von Problemen nimmst.

Wo die Direktive endet

Drei Grenzen sind wichtiger als die Syntax.

1. Navigationen zu Dritten. Ein Link zu einem anderen Host über http:// wird nicht gehoben. Der Besucher verlässt deine Seite über HTTP, und diese Direktive kann das nicht verhindern.
2. Fehlendes HTTPS. Es gibt keinen Ersatz. Antwortet die gehobene URL nicht über HTTPS, schlägt die Anfrage fehl und die Seite verliert die Ressource.
3. HSTS. Die Direktive ersetzt Strict-Transport-Security nicht. HSTS schützt künftige Besuche und die erste Navigation; diese Direktive schützt die Anfragen der aktuellen Seite.

Die Spezifikation behandelt auch WebSocket-Verbindungen getrennt: Eine unsichere ws://-Verbindung wird zu wss:// gehoben, wenn die Direktive greift (Abschnitt 5, gelesen am 2026-11-03). Wir haben keinen echten WebSocket-Endpunkt getestet, deshalb notieren wir das als dokumentiertes Verhalten, nicht als Messergebnis.

Bleibt eine Crawler-Frage ohne Antwort. Wir haben nicht getestet, ob Googlebot oder ein KI-Crawler diese Direktive befolgt. Ein Crawler, der wie ein aktueller Browser rendert, sollte die Umschreibung erhalten, aber wir haben für keinen eine Messung und werden eine Vermutung nicht als Ergebnis ausgeben.

Eine Migrationsreihenfolge, die die Seite nicht bricht

So würde ich auf einer Site vorgehen, die seit Jahren http:// fest im Code trägt.

1. Templates erfassen. Führe beide Befehle auf den wichtigen Seiten aus, nicht nur auf der Startseite, und speichere die Ausgabe in einer Datei.
2. Reparieren, was du kontrollierst. Stelle Bilder, Schriften und Skripte derselben Site zuerst auf HTTPS um. Diese Ausfälle sind sichtbar und in einem Deployment behoben.
3. Jeden Dritten prüfen. Frage nach einer HTTPS-URL. Hat ein Anbieter keine, ersetze oder entferne die Ressource, bevor du erzwingst.
4. Eine Crawl-Runde im Report-Only-Modus. Vergleiche die Berichte mit dem Inventar. Eine URL im Bericht, die im Inventar fehlt, hat dein Quellcode-Scan übersehen.
5. Erzwingen und prüfen. Wechsle auf den erzwingenden Header, lade mit offenem Netzwerk-Panel neu und bestätige, dass keine Anfrage mehr über http:// läuft. Behandle HSTS als eigene Entscheidung.

Das Ergebnis ist das Inventar plus der Vergleich mit den Berichten, nicht die Header-Zeile. Der Header braucht zehn Sekunden. Das Inventar ist die Arbeit.

Drei Wege, es falsch zu machen

Alle drei scheitern still beim ersten Laden, und zwei sehen nach einem CDN-Problem aus.

1. Erzwingen, bevor der Anbieter HTTPS kann. Die Anfrage wird umgeschrieben, der Server des Anbieters antwortet nicht auf Port 443, und die Ressource verschwindet. Ein HTTP-Retry findet nicht statt.
2. Annehmen, es decke Top-Level-Links ab. Ein Link zum Partner über http:// schickt den Besucher weiter über HTTP. Dafür ist HSTS da.
3. Beide CSP-Direktiven stapeln. block-all-mixed-content ist veraltet und tut nichts, wenn die Upgrade-Direktive vorhanden ist. Zwei Zeilen wirken sicherer; eine ist die richtige Konfiguration.

Wann du es nicht einsetzen solltest

Wenn die Seite noch von einem Drittanbieter-Skript abhängt, das nur über HTTP existiert, bricht das Erzwingen dieses Skript beim ersten Laden. Wenn du den ersten Besuch vor einem Downgrade-Angriff schützen willst, ist HSTS das Werkzeug, mit eigenen Entscheidungen zu max-age und preload. Wenn du nur wenige unsichere URLs hast, editiere sie direkt: Diese Direktive ist für den langen Schwanz, den du diese Woche nicht schaffst.

Wir können nicht sagen, wie viel Traffic ein fehlgeschlagenes Upgrade kostet. Das hängt davon ab, welche Ressource ausfällt und was die Seite ohne sie tut. Miss die Seite, nicht den Header.

Häufige Fragen

Ist das dasselbe wie HSTS?

Nein. HSTS sagt dem Browser, für künftige Anfragen an einen Host HTTPS zu verwenden. upgrade-insecure-requests schreibt unsichere Anfragen der aktuellen Seite um. Die W3C-Spezifikation trennt beides und sagt, dass diese Direktive HSTS nicht ersetzt (gelesen am 2026-11-03).

Verschwinden die Warnungen zu gemischten Inhalten?

Die meisten Anfragen für gemischte Inhalte werden vor dem Senden umgeschrieben, laufen also nicht mehr im Klartext. Eine Ressource ohne HTTPS-Version repariert die Direktive nicht: Diese Anfrage schlägt fehl.

Funktioniert es im meta-Tag?

Ja, im Dokument, das es trägt. Ein Response-Header deckt jede HTML-Antwort ab, die du konfigurierst; ein meta-Tag deckt nur seine Seite ab.

Was ist der Upgrade-Insecure-Requests-Request-Header?

Ein anderer Header. Der Browser sendet Upgrade-Insecure-Requests: 1, um mitzuteilen, dass er heben kann. Ein Server kann damit eine 307-Weiterleitung für unsichere Anfragen zurückgeben. Das ist Fähigkeitserkennung, nicht die erzwingende Direktive.

Funktioniert es mit einem CDN?

Ja, wenn das CDN den Response-Header durchlässt. Prüfe nach dem Deployment eine Antwort mit curl -sI. Wir haben die Header-Behandlung nicht bei jedem CDN getestet, also prüfe deinen eigenen Edge.

Befolgt Googlebot die Direktive?

Wir haben weder Googlebot noch einen KI-Crawler getestet. Bestätige es mit deinen Logs oder einem gerenderten Fetch, bevor du dich darauf verlässt.

Nächster Schritt

Wenn die Seite nur noch über HTTPS lädt, lautet die nächste Frage, ob der Crawler dasselbe HTML erhält, das du siehst. Prüfe, was ein KI-Crawler tatsächlich erhält, und nutze QueryWins Seitenansicht, um Anfrage und gerendertes Ergebnis nebeneinander zu sehen.