Cos'è il "Mixed Content" e perché il browser ha bloccato l'immagine

Si è caricata una pagina su HTTPS, il lucchetto è nella barra degli indirizzi, eppure un’immagine è assente, uno script non ha funzionato, oppure un intero widget non è apparso. Aprendo la console, eccolo il messaggio: “Mixed Content: The page was loaded over HTTPS, but requested an insecure resource over HTTP. This request has been blocked.”

La pagina è sicura. Una risorsa che ha richiesto non lo era, e il browser ha rifiutato di recuperarla. Questo è tutto ciò che c’è dietro un errore mixed-content, e la correzione solitamente consiste in un singolo carattere, ma è utile capire perché il browser è così severo riguardo a una singola immagine mancante.

Che cosa significa “mixed” qui

Una pagina servita su HTTPS viene consegnata crittografata, e il lucchetto è una promessa al visitatore che tutto su di essa è arrivato allo stesso modo. Poi la pagina richiede una risorsa (un’immagine, uno script, un foglio di stile, un font) usando un semplice indirizzo http://. Quella risorsa arriverebbe non crittografata, su una connessione che chiunque sulla rete potrebbe leggere o modificare.

Questo è il mix: una pagina sicura e una richiesta insicura al suo interno. Il browser non romperà silenziosamente la promessa che il lucchetto ha fatto, quindi interviene. Quello che fa dopo dipende da quanto è pericolosa la risorsa.

Bloccato o solo avvertito

Non tutto il contenuto misto viene trattato allo stesso modo, e questa è la parte che spiega perché a volte un’immagine si carica con un avvertimento e a volte uno script scompare completamente.

Il contenuto attivo viene bloccato completamente. Script, fogli di stile, iframe e tutto ciò che può modificare la pagina o eseguire codice. Se uno di questi viene richiesto su HTTP, il browser rifiuta di caricarlo completamente, perché uno script manomesso potrebbe riscrivere l’intera pagina. È questo che rompe le funzionalità: un widget di pagamento, un tag di analitiche, una mappa che non appare mai.

Il contenuto passivo viene caricato, con un avvertimento, oppure aggiornato. Immagini, video e audio: cose che si visualizzano ma non possono eseguire codice. I browser più vecchi caricavano questi su HTTP e declassavano il lucchetto per avvertire. Quelli moderni tendono sempre più a recuperarli su HTTPS, e falliscono visibilmente solo se ciò non funziona. Quindi un’immagine mancante e uno script non funzionante sono spesso lo stesso difetto sottostante, che si manifesta con diversa gravità.

Come trovarlo e correggerlo

La console nomina la risorsa esatta. È sufficiente leggere l’URL di cui si lamenta, e la correzione è quasi sempre richiedere quella risorsa su https:// invece che su http://.

• Se la risorsa ha una versione HTTPS, va usata. La maggior parte la ha; cambiare http:// in https:// nel proprio markup è l’intera correzione. Se ne sono presenti molte, un indirizzo relativo al protocollo //example.com/... o una direttiva content-security-policy upgrade-insecure-requests le corregge in massa.
• Se la risorsa non ha una versione HTTPS, non è possibile includerla. Un asset di terze parti servito solo su HTTP deve essere sostituito, messo in proxy attraverso il proprio server HTTPS, oppure rimosso. Non esiste un’impostazione del browser che lo renda sicuro, e dire a un visitatore di disabilitare la protezione non è una soluzione.
• Prestare attenzione anche ai dati, non solo al markup. Un URL memorizzato nel database, restituito da un’API, o incollato in un campo rich-text è il motivo solito per cui il mixed content sopravvive a una migrazione verso HTTPS: i template sono stati corretti ma il contenuto no.

Una richiesta che fallisce in questo modo assomiglia molto a una che ha fallito per altri motivi, motivo per cui la riga della console è importante. Se la console invece dice che la richiesta è stata bloccata dalla policy CORS, oppure ritorna come TypeError: Failed to fetch, è un problema diverso con una correzione diversa. È la prima parola dell’errore che rivela la causa.

Perché uno screenshot non è sufficiente per segnalare uno

Un errore di mixed content è invisibile in uno screenshot: la pagina ha semplicemente un vuoto dove dovrebbe esserci qualcosa, e la ragione si trova nella console, che la persona che lo segnala quasi certamente non ha aperto. “L’immagine è mancante” e “il widget di checkout non si è caricato” sono i rapporti che si ricevono, e nessuno dei due riporta la riga della console che dice esattamente quale risorsa HTTP su una pagina HTTPS è stata rifiutata.

Il registro della console che viene acquisito è dove si trova il messaggio di mixed content, con il nome della risorsa e tutto il resto, quindi chiunque raccoglie il rapporto può capire quale URL insicuro correggere senza dover riprodurre la pagina e aprire gli strumenti di sviluppo.

In un paragrafo

Il mixed content è una risorsa insicura http:// richiesta da una pagina sicura https://, e il browser la blocca, completamente per gli script e altri contenuti attivi, più delicatamente per le immagini, piuttosto che rompere la promessa che il lucchetto fa. La correzione è quasi sempre richiedere la risorsa su HTTPS, sia nel markup che nei dati memorizzati; se non ha una versione HTTPS non può essere inclusa in sicurezza. E poiché il fallimento è un silenzioso vuoto sulla pagina con la ragione nascosta nella console, è meglio acquisirla piuttosto che descriverla.