Perché la pagina del tuo sito in HTTPS carica ancora file in chiaro

La pagina del tuo sito è in HTTPS e può ancora chiedere un file il cui indirizzo è in chiaro. Il canale sicuro dice con quale server è arrivata la pagina, non se i file che la pagina chiede dopo sono arrivati allo stesso modo. Quei file si chiamano mixed content. Il 2 novembre 2026 ho letto la bozza degli editori, ultima modifica 23 febbraio 2023, e la pagina MDN, ultima modifica 15 agosto 2026. La bozza dice di citarla solo come lavoro in corso. Non ho misurato un browser. La Raccomandazione su w3.org non l'ho aperta. Secure Contexts, Fetch, HTML e la specifica di upgrade-insecure-requests non li ho aperti.

Questa pagina non descrive il banner dei cookie. Il file che il sito carica da fuori, e il controllo sui byte, sta nell'articolo perché il file che il tuo sito carica da fuori può cambiare. Non lo riscrivo. L'header che chiede al browser di restare su HTTPS è un'altra pagina. Non l'ho aperta.

La pagina sicura non copre il file in chiaro

L'introduzione non è normativa. Dice che HTTPS garantisce che nessuno, tra il browser e il server della pagina, abbia letto o cambiato i dati di quella pagina. La garanzia si indebolisce se la pagina poi carica uno script o un'immagine su un canale in chiaro. Uno script in chiaro può leggere o modificare dati per conto di chi usa il sito. Un'immagine in chiaro può mostrare un'informazione sbagliata, impostare un cookie, o cambiare la scritta di un pulsante. Non descrivo come si fa.

Le versioni precedenti lasciavano caricare di default immagini, audio e video, e permettevano scaricamenti in chiaro che escono dalla sandbox del browser. Chi usava il sito vedeva un segnale a metà, per esempio il lucchetto tolto. Quel segnale non ha fermato il fenomeno. Questa bozza consiglia di riscrivere il contenuto che non è già bloccato. Se la riscrittura non può avvenire, il file va bloccato. Non consiglia di riscrivere i tipi già bloccati, per limitare il cambiamento visibile sul web. Gli scaricamenti misti, dice, vanno bloccati.

La sezione 2 definisce la richiesta mixed content se il suo URL non è un potentially trustworthy URL e il contesto che la carica vieta i contesti di sicurezza misti. La definizione di potentially trustworthy sta in Secure Contexts, che non ho aperto, quindi non aggiungo io quali host contino. La stessa sezione dice che la risposta è mixed content se non è autenticata e il contesto la carica. La frase, così com'è scritta, accosta le due parole inglesi requires e prohibits. Non ne ho scelta una. Non autenticata, nella stessa sezione, vuol dire che l'URL della risposta non è potentially trustworthy: lo si sa dopo, non prima. Un URL autenticato a priori, dice la nota, equivale a un potentially trustworthy URL.

Dentro un contesto che restringe, l'esempio della bozza è questo. La richiesta di uno script in chiaro è mixed content e blockable: il browser restituisce un network error e non carica il file. La richiesta di un'immagine in chiaro è mixed content e upgradeable: il browser può riscrivere lo schema in https, altrimenti blocca. XML usa le stesse due parole per un concetto che non c'entra. La bozza dice che il rischio pratico di confonderli è basso. Non ho aperto XML.

Prima si cambia lo schema, poi si decide il blocco

La sezione 5.1 dice che Fetch, nel main fetch, dovrebbe chiamare la riscrittura della sezione 4.1 tra il passo 3 e il passo 4, prima del controllo che blocca. È l'ordine scritto in questa bozza. Non ho aperto Fetch di oggi, quindi non confermo che il gancio dal vivo sia quello.

La sezione 4.1 lascia la richiesta com'è, e ritorna, se vale una di queste condizioni. L'URL è già potentially trustworthy. L'host è un indirizzo IP. La sezione 4.3 restituisce la stringa Does Not Restrict Mixed Security Contents. La destinazione non è image, audio o video. La destinazione è image e l'initiator è imageset. Se lo schema è http, e nessuna di quelle condizioni ha fatto ritornare, lo schema diventa https e la funzione ritorna. La nota dice che la porta non si modifica: con http è null, e dopo il cambio si legge come 443. Non ho aperto lo standard URL, quindi non ho verificato quella lettura della porta.

imageset, dice la nota, non si riscrive per una ragione storica. Prima delle riscritture il contenuto misto era diviso in blockable e optionally-blockable, e blockable era la scelta per i tipi non diffusi. imageset stava tra i blockable. Quando è arrivata la riscrittura, non è stata applicata ai tipi che erano già blockable. Nella sezione 3.1, imageset corrisponde a un'immagine che usa srcset o picture. Un'immagine normale, con l'initiator vuoto e destinazione image, non è quel caso.

Foto, audio e video con un nome di dominio

La sezione 3.1 chiama upgradeable il contenuto il cui blocco romperebbe una parte grande del web. Non è una dichiarazione che quei file siano sicuri. Sono solo meno catastrofici di altri. L'esempio della bozza è un'icona: se le scritte di due pulsanti si scambiano, l'effetto per chi usa il sito è reale. Il nome vecchio, nella stessa sezione, era optionally-blockable.

Rientrano le richieste con initiator stringa vuota e destinazione image. La nota dice che sono la maggior parte delle immagini, compresi i documenti SVG caricati come immagini, che non possono eseguire script né chiedere altre risorse, e le immagini dei fogli, background-image e border-image. Non rientra l'immagine che usa srcset o picture. Rientrano le richieste con destinazione video, cioè video e source, e quelle con destinazione audio, cioè audio e source.

La stessa sezione 3.1 dice che la categoria è ulteriormente limitata nella sezione 4.4, forzando il fallimento di ogni richiesta con CORS attivo. L'esempio è un'immagine con l'attributo crossorigin: viene bloccata. Il gruppo di lavoro intende ritagliare altri sottoinsiemi blockable. Ho letto la sezione 4.1 e la sezione 4.4: non nominano CORS. Gli elenchi di MDN, nella pagina del 15 agosto 2026, non nominano crossorigin. Non ho unito la frase della 3.1 con gli algoritmi, né con MDN.

La sezione 3.2 dice che è blockable tutto il mixed content che non è upgradeable. Gli esempi tipici sono gli script, i dati di un plugin e XMLHttpRequest. Una navigazione di primo livello non è mixed content: il dettaglio è nella 4.4. Le richieste fatte per un plugin sono blockable. La nota aggiunge che il browser non sempre può mettersi in mezzo: alcuni plugin vecchi, e cita NPAPI, raggiungono la rete senza passare dal browser. Consiglia di bloccare quando si può, e che chi fa il plugin controlli da sé. Non descrivo quel passaggio.

Le due pagine non elencano le stesse cose

MDN dice che i browser riscrivono da HTTP a HTTPS le richieste di immagine, video e audio, e bloccano gli altri tipi in chiaro. Devono anche bloccare gli scaricamenti misti. L'elenco che si riscrive: immagine tramite src, compresi gli SVG, ma non srcset né picture; immagini dei fogli, background-image e border-image; audio tramite src; video tramite src; source per video o audio. L'eccezione è la stessa della sezione 4.1: se l'host è un indirizzo IP, la richiesta si blocca e non si riscrive. MDN distingue un nome di dominio, che viene riscritto, da un host numerico, che viene bloccato. Non riporto il numero dell'esempio e non l'ho provato.

MDN aggiunge che, dopo il cambio di schema, il server remoto o restituisce il file o risponde che non c'è. La bozza non descrive quell'esito. Non ho misurato un server senza la copia in https.

Blockable, su MDN, è tutto ciò che non è upgradable. L'elenco, che MDN dice non esaustivo, aggiunge il foglio di stile collegato, il frame, fetch, XMLHttpRequest, tutti i valori url nei fogli, e tra questi nomina @font-face, cursor e anche background-image, poi l'oggetto, sendBeacon, l'immagine tramite srcset o picture, e i web font. background-image sta quindi in tutti e due gli elenchi di MDN. La bozza mette background-image e border-image tra gli upgradeable, e non li mette tra i blockable. Non ho scelto un elenco.

Sulle risorse locali MDN dice che gli indirizzi file e il loopback, http://127.0.0.1/ e http://localhost/, sono origini sicure, come HTTPS. Caricarli da un contesto sicuro lascia il contesto sicuro. Se però un file locale chiede poi un indirizzo http, quella richiesta è mixed content. La bozza affida potentially trustworthy a Secure Contexts, che non ho aperto. Riporto la frase di MDN e non ho controllato da solo la definizione della bozza.

MDN segna la funzione come ampiamente disponibile da gennaio 2020, con una nota che alcune parti variano. Non è una misura di questo sito. Nel paragrafo sui termini vecchi, MDN chiama active mixed content l'ex blockable, script e fogli di stile, e passive l'ex optionally-blockable, immagini, video e audio. L'insieme upgradeable della bozza parte da optionally-blockable. I tipi nuovi, dice MDN, ci si aspetta che siano blockable, e qualche tipo upgradeable potrebbe diventarlo. I fogli di stile sono blockable sia nel vocabolario vecchio sia nell'elenco attuale di MDN.

MDN scrive che Safari blocca di default tutto il contenuto misto, e che gli altri browser hanno un meccanismo per bloccarlo. Nomina anche dei controlli esterni e gli avvisi in console. Non ho aperto una console, non ho eseguito quei controlli e non ho misurato un browser.

Sulla direttiva, la sezione 6.1 dice che block-all-mixed-content è obsoleta, perché il mixed content che non si può riscrivere è già bloccato. upgrade-insecure-requests non è obsoleta: permette a chi pubblica di riscrivere anche il contenuto blockable. Questa specifica, di default, riscrive solo l'upgradeable. MDN dice la stessa cosa sulla direttiva che riscrive tutte le richieste, compresi i tipi blockable. Non ho aperto la specifica di quella direttiva, e non consiglio di usare la direttiva obsoleta. Non descrivo l'header della pagina successiva.

Quando la pagina vieta il file in chiaro

La sezione 4.3 chiede se le impostazioni vietano i contesti di sicurezza misti. Se l'origine è potentially trustworthy, ritorna Prohibits Mixed Security Contexts. Se l'oggetto globale è una finestra, percorre i navigable antenati: se l'origine del documento attivo di uno di essi è potentially trustworthy, ritorna la stessa stringa. Altrimenti ritorna Does Not Restrict Mixed Security Contexts. La frase di apertura della stessa sezione annuncia l'altra risposta come Does Not Prohibit Mixed Security Contexts. Quella stringa non è quella che l'algoritmo restituisce.

La sezione 4.1, nel punto in cui decide di non riscrivere, cerca Does Not Restrict Mixed Security Contents. La sezione 4.4 cerca Does Not Restrict Mixed Security Contexts. La sezione 4.5 cerca Does Not Restrict Mixed Content. La sezione 7.1 cerca Restricts Mixed Content. Sono quattro stringhe diverse. Non ho corretto una sezione con l'altra.

La nota della 4.3 spiega il perché del giro sugli antenati, con quattro casi. Una pagina http che carica http è ammessa. Una pagina https che carica http, scrive la nota, è bloccata. Una pagina http che incornicia una pagina https, e questa carica http, è bloccata, perché la pagina incorniciata è sicura. Una pagina https che incornicia un indirizzo data, e questo carica http, è bloccata. La nota parla di blocco. La sezione 5.1 dice di riscrivere prima di applicare il blocco. Per una foto che rientra nella 4.1, l'indirizzo è già https quando arriva il controllo della 4.4. Non ho fuso la nota con quell'ordine. I worker usano lo stesso controllo delle impostazioni. MDN dice che anche plugin e worker vengono riscritti o bloccati allo stesso modo. La nota della sezione 3.2, sui plugin che non passano dal browser, resta quella che ho già riportato. Non le ho unite.

La richiesta e la risposta

La sezione 4.4 ritorna allowed se vale una di queste condizioni. La 4.3 restituisce Does Not Restrict Mixed Security Contexts. L'URL della richiesta è potentially trustworthy. Il browser ha avuto istruzione di permettere il mixed content, come nella sezione 7.2. La destinazione è document e il contesto di navigazione di arrivo non ha un genitore: la navigazione di primo livello è esclusa, e il browser può comunque controllare l'invio di un modulo in chiaro. Altrimenti ritorna blocked.

Insieme alla 5.1, la riscrittura avviene prima. Una foto riscritta è poi ammessa perché il suo URL è https, se quell'URL è potentially trustworthy. Uno script, un'immagine imageset o un'immagine il cui host è un indirizzo IP non vengono riscritti, e la 4.4 li blocca. Non ho aperto Fetch, quindi questo è l'ordine della bozza, non un controllo del gancio dal vivo.

La sezione 4.5 fa lo stesso controllo sulla risposta. Ritorna allowed se la 4.3 restituisce Does Not Restrict Mixed Content, se l'URL della risposta è potentially trustworthy, se c'è l'override dell'utente, o se è una navigazione document di primo livello. Altrimenti blocked. Lo scopo, dice la nota, è bloccare una richiesta blockable la cui connessione non è autenticata, e impedire che un service worker restituisca una risposta non autenticata per una richiesta blockable. La stringa Does Not Restrict Mixed Content non è la stringa che la 4.3 restituisce. Non ho sostituito una all'altra.

Lo scaricamento non cambia schema

La sezione 2 chiama mixed download una risorsa che il browser tratta come scaricamento, partita da un contesto sicuro e scaricata su una connessione in chiaro. La sezione 5.2 dice che il passo 3 di Process a navigate response dovrebbe interrompere lo scaricamento se l'URL del documento attivo di partenza è potentially trustworthy e un URL nella lista della risposta non lo è. Lo stesso per il passo 6.2 di download the hyperlink. Non ho aperto HTML, quindi non ho verificato quei passi nel testo di HTML.

Gli scaricamenti non si riscrivono come gli altri tipi, perché il browser non sempre sa, prima di chiedere la risorsa, che sarà uno scaricamento. La risorsa può aver già attraversato la rete prima dell'interruzione. Un'informazione sensibile può quindi passare in rete anche se poi il browser blocca lo scaricamento. La bozza dice che è in genere inevitabile, perché il browser può scoprire che si tratta di uno scaricamento solo con la risposta finale, e che bloccare comunque spinge chi pubblica a servire gli scaricamenti su un canale sicuro. Non descrivo come far uscire un file.

MDN dice che i browser dovrebbero bloccare gli scaricamenti misti, e che un sito sicuro non dovrebbe includerli. Una nota a parte dice che i browser di solito li bloccano di default, informano chi usa il sito e lasciano tenere o scartare il file. L'override di un blocco, nella bozza, sta nella sezione 7.2 ed è generale: non è scritto come quella scelta tra tenere e scartare. Non ho unito le due frasi.

Esempio ipotetico: la foto e lo script della vetrina

I nomi bottega.example e fornitore.example sono di scuola. Non ho letto una risposta e non ho misurato un browser.

La pagina è https://bottega.example/scheda. Chiede la foto http://fornitore.example/vetrina.png come immagine normale: nome di dominio, non un indirizzo IP, initiator non imageset. La sezione 4.1 cambia lo schema in https e ritorna. La sezione 4.4 poi la ammette se l'URL in https è potentially trustworthy. Non ho aperto Secure Contexts, quindi non aggiungo un'altra eccezione. Se la riscrittura non può avvenire, l'introduzione dice che la richiesta va bloccata. MDN aggiunge che il server o restituisce il file o risponde che non c'è. La bozza non lo dice. Non l'ho misurato.

La stessa pagina chiede lo script http://fornitore.example/cassa.js. La destinazione non è image, audio o video, quindi la 4.1 non lo riscrive. La 4.4 lo blocca. L'esempio della sezione 2 dice che il browser restituisce un network error e non carica lo script. Non ho misurato un browser.

Se l'host della foto fosse un indirizzo IP, la 4.1 ritornerebbe senza modificare la richiesta, e la 4.4 la bloccherebbe. MDN dice la stessa cosa per l'host numerico. Non stampo un numero. Se la foto usasse srcset o picture, l'initiator imageset non si riscrive, per la ragione storica della 4.1, e poi viene bloccato. Un collegamento di scaricamento verso un indirizzo http non si riscrive. La bozza dice che i byte possono aver già attraversato la rete prima dello stop.

Sul foglio di stile le due pagine restano affiancate. La bozza mette background-image tra gli upgradeable. MDN lo mette sia tra quelli che si riscrivono sia dentro la frase che chiama blockable tutti i valori url dei fogli. Sull'immagine con crossorigin, la sezione 3.1 dice che è bloccata e rimanda alla 4.4. Le sezioni 4.1 e 4.4 non nominano CORS. Gli elenchi di MDN non nominano crossorigin. Non ho unito queste frasi.

Il rischio che la bozza scrive da sola

La sezione 7 dice che riscrivere l'upgradeable dovrebbe migliorare sicurezza e riservatezza, perché più traffico non resta in chiaro. C'è un rischio: un'immagine in chiaro la cui copia https reindirizza verso un tracciamento caricherebbe qualcosa che chi ha scritto la pagina non aveva scelto. La bozza chiama questi casi estremamente rari, e dice che il rischio è limitato perché si riscrive solo l'upgradeable, non gli script blockable. Non ho cercato un reindirizzamento del genere e non descrivo come costruirlo.

La sezione 7.1, se la 4.3 restituisce Restricts Mixed Content, permette al browser di avvisare se un modulo ha un'azione che non è un potentially trustworthy URL, di avvisare e lasciare interrompere l'invio, anche se l'azione poi reindirizza verso un URL non affidabile, e di trattare l'invio come blockable anche al primo livello. Quella stringa, Restricts Mixed Content, non è una stringa che la 4.3 restituisce. Non ho corretto la 7.1.

La sezione 7.2 permette al browser di lasciare a chi usa il sito la scelta di scavalcare un blocco, su una pagina. La nota dice che offrire uno script in chiaro è particolarmente pericoloso, cita RFC 6919, e dice che il browser non dovrebbe presentare quella scelta senza aver considerato e comunicato il rischio. Permette anche di scavalcare la riscrittura automatica. Qualunque controllo del genere deve essere esposto anche alle API di accessibilità. Non descrivo come si disattiva il blocco.

Che cosa questa pagina lascia stare

Non ho aperto Secure Contexts, quindi non ho un elenco mio di quali URL siano potentially trustworthy. Non ho aperto Fetch, quindi l'ordine tra riscrittura e blocco è quello della sezione 5.1, non un controllo del testo di Fetch. Non ho aperto HTML, quindi non ho verificato i passi dello scaricamento. Non ho aperto la specifica di upgrade-insecure-requests. Non ho aperto la Raccomandazione pubblicata. Non ho misurato un browser, non ho letto una console e non ho eseguito i controlli che MDN nomina. La pagina sull'impronta dei file caricati da fuori non è stata riscritta. L'header della pagina successiva non è stato aperto. Il banner dei cookie non è questa pagina.

Fonte: Mixed Content, Editor's Draft, lavoro in corso, ultima modifica 23 febbraio 2023, sezioni 1, 2, 3.1, 3.2, 4.1, 4.2, 4.3, 4.4, 4.5, 5.1, 5.2, 6.1, 7, 7.1 e 7.2, letta il 2 novembre 2026. Pagina MDN Mixed content, ultima modifica 15 agosto 2026, letta lo stesso giorno. Non ho misurato un browser.

I due schemi nel testo sono disegni di questa pagina, non fotografie. La copertina non è stata cambiata.