Limitare la riscrittura dei contenuti del proxy con no-transform e HTTPS

Un proxy che trasforma i contenuti può modificare una risposta lungo il percorso verso il browser: ricomprimere un'immagine, riscrivere il markup o inserire JavaScript di supporto. Una pagina che funziona su una rete e riceve markup sconosciuto su un'altra può stare incontrando proprio quel comportamento dell'intermediario.

Per un sito che gestisci, HTTP fornisce una direttiva di risposta esplicita:

Cache-Control: no-transform

La RFC 9111 richiede che un intermediario che riceve questa direttiva di risposta lasci il contenuto non trasformato, indipendentemente dal fatto che implementi una cache. È rilevante per la ricompressione delle immagini e l'iniezione di markup, non solo per se un oggetto viene memorizzato.

Mantienila insieme alla politica di cache esistente

Se una risposta ha già direttive di cache, aggiungi il requisito deliberatamente invece di scartare il resto della politica. Ad esempio, una risorsa memorizzabile pubblicamente potrebbe avere:

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

Questo esempio conserva una politica di freschezza di un'ora e al tempo stesso vieta la trasformazione dei contenuti. no-transform non implica no-store e non disattiva l'ordinaria elaborazione del trasferimento. Impostala sulle risposte il cui contenuto originale conta, comprese le risposte immagine separate ove opportuno.

La direttiva opera tramite l'osservanza dell'intermediario. Non impedisce crittograficamente a un dispositivo di rete di ignorare l'istruzione.

Proteggi anche il trasporto

HTTPS dà al browser una connessione con autenticazione e protezione dell'integrità verso il suo peer TLS. Un normale proxy dell'operatore che lascia passare traffico cifrato non può inserire silenziosamente uno script in quella connessione protetta. Mantieni attiva la verifica dei certificati; un proxy di ispezione fidato localmente che termina il TLS è un'altra configurazione.

Servi la pagina e le sue risorse dipendenti tramite HTTPS. Reindirizza i visitatori HTTP su HTTPS e valuta HSTS per un'implementazione che possa supportarlo in modo costante. Un semplice reindirizzamento inizia con uno scambio HTTP non protetto per un visitatore che ha usato un URL HTTP; una politica HSTS appresa in precedenza o precaricata cambia quella scelta iniziale.

Bloccare uno script iniettato può ridurne gli effetti visibili, ma la risposta potrebbe già contenere HTML modificato o URL di immagini riscritti. Sostituire un vecchio nome di funzione, aggiungere un commento insolito o mappare un indirizzo di iniezione storico non stabilisce l'integrità dei contenuti per l'intermediario successivo.

Quando indaghi su una segnalazione, confronta la risposta ricevuta con il contenuto previsto dell'origine e individua dove termina il TLS. Quell'evidenza è più utile che trattare ogni script sconosciuto come un difetto nel codice dell'applicazione del sito stesso.