Begränsa proxyns innehållsomskrivning med no-transform och HTTPS

En proxy som transformerar innehåll kan ändra ett svar på vägen till webbläsaren: komprimera om en bild, skriva om markup eller infoga stödjande JavaScript. En sida som fungerar i ett nätverk och får okänd markup i ett annat kan möta just detta mellanhands beteende.

För en webbplats du driver tillhandahåller HTTP ett uttryckligt svarsdirektiv:

Cache-Control: no-transform

RFC 9111 kräver att ett mellanhand som tar emot detta svarsdirektiv lämnar innehållet otransformerat, oavsett om mellanhanden implementerar en cache. Det är relevant för bildomkomprimering och infogning av markup, inte bara för om ett objekt lagras.

Behåll det tillsammans med den befintliga cachepolicyn

Om ett svar redan har cachedirektiv, lägg till kravet medvetet i stället för att kasta bort resten av policyn. En offentligt cachebar resurs kan till exempel ha:

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

Detta exempel bevarar en färskhetspolicy på en timme samtidigt som det förbjuder innehållstransformering. no-transform innebär inte no-store och inaktiverar inte vanlig överföringsbehandling. Ange det på de svar vars ursprungliga innehåll spelar roll, inklusive separata bildsvar där det är lämpligt.

Direktivet verkar genom mellanhandens efterlevnad. Det hindrar inte kryptografiskt att en nätverksenhet ignorerar instruktionen.

Skydda även transporten

HTTPS ger webbläsaren en anslutning med autentisering och integritetsskydd till sin TLS-motpart. En vanlig operatörsproxy som släpper igenom krypterad trafik kan inte i tysthet infoga ett skript i den skyddade anslutningen. Behåll certifikatverifieringen; en lokalt betrodd inspektionsproxy som avslutar TLS är en annan uppsättning.

Servera sidan och dess beroende resurser över HTTPS. Omdirigera HTTP-besökare till HTTPS och överväg HSTS för en driftsättning som konsekvent kan stödja det. Enbart en omdirigering börjar med ett oskyddat HTTP-utbyte för en besökare som använde en HTTP-URL; en tidigare inlärd eller förladdad HSTS-policy ändrar det första valet.

Att blockera ett infogat skript kan minska dess synliga effekter, men svaret kan redan innehålla ändrad HTML eller omskrivna bildadresser. Att ersätta ett gammalt funktionsnamn, lägga till en ovanlig kommentar eller mappa en historisk injektionsadress etablerar inte innehållsintegritet för nästa mellanhand.

När du undersöker en rapport, jämför det mottagna svaret med ursprungets avsedda innehåll och identifiera var TLS avslutas. Det beviset är mer användbart än att behandla varje okänt skript som ett fel i webbplatsens egen applikationskod.