Proxy-Inhaltsumschreibung mit no-transform und HTTPS begrenzen

Ein transformierender Proxy kann eine Antwort auf dem Weg zum Browser verändern: ein Bild neu komprimieren, Markup umschreiben oder unterstützendes JavaScript einfügen. Eine Seite, die in einem Netz funktioniert und in einem anderen unbekanntes Markup erhält, trifft möglicherweise genau auf dieses Verhalten eines Zwischenglieds.

Für eine von Ihnen betriebene Website bietet HTTP eine ausdrückliche Antwortdirektive:

Cache-Control: no-transform

RFC 9111 verlangt, dass ein Zwischenglied, das diese Antwortdirektive erhält, den Inhalt unverändert lässt, unabhängig davon, ob es einen Cache betreibt. Das ist für Bildneukomprimierung und Markup-Einfügung relevant, nicht nur dafür, ob ein Objekt gespeichert wird.

Behalten Sie sie bei der bestehenden Cache-Richtlinie

Wenn eine Antwort bereits Cache-Direktiven hat, fügen Sie die Anforderung bewusst hinzu, statt den Rest der Richtlinie zu verwerfen. Ein öffentlich cachebares Asset könnte zum Beispiel haben:

Cache-Control: public, max-age=3600, no-transform

Dieses Beispiel bewahrt eine Frische-Richtlinie von einer Stunde und verbietet zugleich die Inhaltsumwandlung. no-transform bedeutet nicht no-store und deaktiviert nicht die gewöhnliche Übertragungsverarbeitung. Setzen Sie sie bei den Antworten, deren Originalinhalt wichtig ist, einschließlich separater Bildantworten, wo dies angebracht ist.

Die Direktive wirkt durch die Befolgung seitens des Zwischenglieds. Sie verhindert kryptografisch nicht, dass ein Netzwerkgerät die Anweisung ignoriert.

Schützen Sie auch den Transport

HTTPS gibt dem Browser eine Verbindung mit Authentifizierung und Integritätsschutz zu seinem TLS-Peer. Ein gewöhnlicher Carrier-Proxy, der verschlüsselten Verkehr durchleitet, kann nicht stillschweigend ein Skript in diese geschützte Verbindung einfügen. Lassen Sie die Zertifikatsprüfung aktiv; ein lokal vertrauenswürdiger Inspektionsproxy, der TLS terminiert, ist eine andere Anordnung.

Liefern Sie die Seite und ihre abhängigen Ressourcen über HTTPS aus. Leiten Sie HTTP-Besucher auf HTTPS um und erwägen Sie HSTS für ein Deployment, das ihn durchgängig unterstützen kann. Eine Weiterleitung allein beginnt mit einem ungeschützten HTTP-Austausch für einen Besucher, der eine HTTP-URL verwendet hat; eine zuvor gelernte oder vorab geladene HSTS-Richtlinie ändert diese erste Wahl.

Das Blockieren eines eingefügten Skripts kann seine sichtbaren Auswirkungen verringern, aber die Antwort kann bereits geändertes HTML oder umgeschriebene Bild-URLs enthalten. Einen alten Funktionsnamen zu ersetzen, einen ungewöhnlichen Kommentar hinzuzufügen oder eine historische Einfügeadresse zuzuordnen, begründet keine Inhaltsintegrität für das nächste Zwischenglied.

Wenn Sie eine Meldung untersuchen, vergleichen Sie die empfangene Antwort mit dem beabsichtigten Inhalt des Ursprungs und ermitteln Sie, wo TLS endet. Dieser Nachweis ist nützlicher, als jedes unbekannte Skript als Fehler im eigenen Anwendungscode der Website zu behandeln.