upgrade-insecure-requests: aggiornare ogni richiesta non sicura prima che parta

upgrade-insecure-requests è una direttiva Content-Security-Policy che riscrive un URL http:// in https:// prima che il browser invii la richiesta. Basta un header di risposta e tutte le sotto-risorse http:// della pagina vengono caricate via https://. È una riscrittura, non una riparazione: se l'URL sicuro non risponde, la richiesta fallisce senza tornare a HTTP. Non sostituisce nemmeno HSTS, perché i link verso un altro dominio restano intatti.

Cosa cambia upgrade-insecure-requests

Agisce prima del blocco dei contenuti misti. La specifica W3C dice che il meccanismo aggiorna le richieste di risorse «a priori» non sicure «before fetching them», e che la riscrittura avviene prima dei controlli sui contenuti misti e su CSP. Per questo una richiesta aggiornata non viene segnalata come contenuto misto (Upgrade Insecure Requests, Candidate Recommendation dell'8 ottobre 2015, consultato il 2026-11-03). MDN descrive lo stesso comportamento e classifica la funzione come Baseline ampiamente disponibile da aprile 2018 (MDN, consultato il 2026-11-03).

Tutto il valore sta in quel momento: il browser non invia mai la richiesta non sicura, quindi il blocco dei contenuti misti non ha nulla da intercettare.

La quarta riga è quella che si dimentica. Una navigazione dentro lo stesso sito viene aggiornata; una navigazione verso un altro host no (stessa specifica, sezione 1.2.2, consultata il 2026-11-03). Per questo la direttiva non sostituisce HSTS.

Come aggiungere upgrade-insecure-requests

Un header di risposta basta. Mettilo su ogni risposta HTML che può contenere un URL non sicuro.

Content-Security-Policy: upgrade-insecure-requests

Se l'hosting non permette di modificare gli header, resta il tag meta. Copre solo il documento che lo contiene.

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

Non aggiungere block-all-mixed-content accanto. MDN segna quella direttiva come obsoleta, e la specifica W3C dice che upgrade-insecure-requests viene valutata prima, quindi block-all-mixed-content non fa nulla quando ci sono entrambe (MDN, consultato il 2026-11-03). Scegline una.

Trova gli URL non sicuri prima di applicare

Inizia contando. I due comandi qui sotto richiedono un minuto e producono un elenco che puoi verificare. Non trovano tutto: gli URL costruiti da JavaScript e quelli dentro il CSS non compaiono nel secondo comando.

# 1. La pagina invia già la direttiva?
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. Quali risorse sono ancora su http://?
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

Esegui il secondo comando sui template che generano più pagine, non solo sulla home. Checkout, articoli e landing page caricano spesso terze parti diverse. Se dopo la correzione restano avvisi di contenuti misti, la diagnosi è in come correggere i contenuti misti (in inglese).

Un deploy in modalità report ti dà l'elenco reale. Il browser invia report di violazione senza riscrivere nulla, così puoi confrontarli con quello che ha trovato la scansione del codice.

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

report-uri è il meccanismo più vecchio. report-to è la configurazione più recente, ma non sono intercambiabili su ogni hosting. Non abbiamo testato la consegna dei report su ogni CDN: verifica che il tuo endpoint riceva qualcosa prima di considerare un report vuoto una prova che non ci sono problemi.

Dove si ferma la direttiva

Tre limiti contano più della sintassi.

1. Navigazioni verso terzi. Un link verso un altro host su http:// non viene aggiornato. Il visitatore lascia la tua pagina via HTTP, e questa direttiva non può impedirlo.
2. HTTPS mancante. Non c'è ripiego. Se l'URL aggiornato non risponde in HTTPS, la richiesta fallisce e la pagina perde quella risorsa.
3. HSTS. La direttiva non sostituisce Strict-Transport-Security. HSTS protegge le visite future e la prima navigazione; questa direttiva protegge le richieste della pagina corrente.

La specifica tratta anche le connessioni WebSocket a parte: una connessione ws:// non sicura viene aggiornata a wss:// quando la direttiva si applica (sezione 5, consultata il 2026-11-03). Non abbiamo testato un endpoint WebSocket reale, quindi lo registriamo come comportamento documentato, non come risultato misurato.

Resta una domanda sui crawler senza risposta. Non abbiamo testato se Googlebot o un crawler IA rispetta questa direttiva. Un crawler che renderizza come un browser attuale dovrebbe ricevere la riscrittura, ma non abbiamo misure per nessuno e non presenteremo un'ipotesi come risultato.

Un ordine di migrazione che non rompe la pagina

Questo è l'ordine che userei su un sito con anni di URL http:// scritti a mano.

1. Inventaria i template. Esegui i due comandi sulle pagine importanti, non solo sulla home, e salva l'output in un file.
2. Correggi ciò che controlli. Porta prima immagini, font e script dello stesso sito su HTTPS. Quei guasti si vedono e si riparano in un deploy.
3. Controlla ogni terza parte. Chiedi un URL HTTPS. Se il fornitore non ce l'ha, sostituisci o rimuovi la risorsa prima di applicare.
4. Modalità report per un ciclo di scansione. Confronta i report con l'inventario. Un URL nei report ma non nell'inventario è uno che la scansione del codice ha saltato.
5. Applica e verifica. Passa all'header di applicazione, ricarica con il pannello di rete aperto e conferma che nessuna richiesta sia ancora su http://. Tieni HSTS come decisione separata.

Il risultato è l'inventario e il confronto con i report, non la riga dell'header. L'header richiede dieci secondi. L'inventario è il lavoro.

Tre modi di sbagliare

Tutti e tre falliscono in silenzio al primo caricamento, e due sembrano un problema del CDN.

1. Applicare prima che il fornitore supporti HTTPS. La richiesta viene riscritta, il server del fornitore non risponde sulla porta 443 e la risorsa sparisce. Nessun retry HTTP.
2. Credere che copra i link di primo livello. Un link a un partner su http:// manda ancora il visitatore via HTTP. Per quello serve HSTS.
3. Impilare le due direttive CSP. block-all-mixed-content è obsoleta e non fa nulla quando la direttiva di aggiornamento è presente. Due righe sembrano più sicure; una è la configurazione corretta.

Quando non usarla

Se la pagina dipende ancora da uno script di terze parti disponibile solo in HTTP, applicare la direttiva lo rompe al primo caricamento. Se devi proteggere la prima visita da un attacco di downgrade, lo strumento è HSTS, con le sue decisioni su max-age e preload. Se hai solo pochi URL non sicuri, correggili direttamente: questa direttiva serve per la coda lunga che non riesci a sistemare questa settimana.

Non possiamo dire quanto traffico costa un aggiornamento fallito. Dipende da quale risorsa si rompe e da cosa fa la pagina senza di essa. Misura la pagina, non l'header.

Domande frequenti

È la stessa cosa di HSTS?

No. HSTS dice al browser di usare HTTPS per le richieste future verso un host. upgrade-insecure-requests riscrive le richieste non sicure della pagina corrente. La specifica W3C separa le due cose e dice che questa direttiva non sostituisce HSTS (consultata il 2026-11-03).

Elimina gli avvisi di contenuti misti?

La maggior parte delle richieste di contenuti misti viene riscritta prima di uscire, quindi non viaggia più in chiaro. Non ripara una risorsa che non esiste in HTTPS: quella richiesta fallisce.

Funziona in un tag meta?

Sì, nel documento che lo contiene. Un header di risposta copre tutte le risposte HTML che configuri; un tag meta copre solo la sua pagina.

Cos'è l'header di richiesta Upgrade-Insecure-Requests?

È un altro header. Il browser invia Upgrade-Insecure-Requests: 1 per dire che sa aggiornare. Un server può usarlo per restituire un redirect 307. È rilevamento di capacità, non la direttiva di applicazione.

Funziona con un CDN?

Sì, se il CDN trasmette l'header di risposta. Controlla una risposta con curl -sI dopo il deploy. Non abbiamo testato la gestione degli header di ogni CDN, quindi verifica il tuo edge.

Googlebot la rispetta?

Non abbiamo testato Googlebot né alcun crawler IA. Confermalo con i tuoi log o con un fetch renderizzato prima di farci affidamento.

Prossimo passo

Quando la pagina carica solo via HTTPS, la domanda successiva è se il crawler riceve lo stesso HTML che vedi tu. Verifica cosa riceve davvero un crawler IA e usa la vista pagina di QueryWin per confrontare richiesta e risultato renderizzato.