Contenuto misto

TL;DR — Il contenuto misto si verifica quando una pagina sicura https:// carica qualcosa — un’immagine, uno script, un foglio di stile — su http:// non sicuro. Questo mescola una pagina sicura con elementi non sicuri, vanificando lo scopo di HTTPS. I browser bloccano i tipi pericolosi (script, stili, iframe) e avvisano sui tipi più lievi (immagini, media). È la cosa più comune che rompe un sito subito dopo il passaggio a HTTPS, e la soluzione è semplice: far caricare ogni risorsa su https://.

Cos’è il contenuto misto

Quando sposti un sito su HTTPS, la pagina stessa si carica in modo sicuro. Ma una pagina non è mai solo l’HTML — include immagini, script, fogli di stile, font, video e talvolta frame incorporati da altri luoghi. Se uno di questi elementi viene ancora richiesto su http:// semplice, hai contenuto misto: una pagina sicura che trasporta carico non sicuro. Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

Come dice lo stesso spiegatore di Google, “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (traduzione) «Una pagina ha contenuto misto quando il suo HTML iniziale viene caricato su una connessione HTTPS sicura, ma altre risorse (come immagini, video, fogli di stile e script) vengono caricate su una connessione HTTP non sicura.»

Questo è importante perché gli elementi non sicuri riaprono esattamente il buco che HTTPS aveva chiuso. Chiunque si trovi sulla rete tra il visitatore e il server può leggere o manomettere quelle richieste http:// — quindi il lucchetto nella barra degli indirizzi promette più sicurezza di quanta la pagina ne abbia realmente.

I due tipi e cosa fanno i browser

I browser non trattano tutto il contenuto misto allo stesso modo. Lo classificano in base al danno che la risorsa non sicura potrebbe causare:

• Contenuto misto attivo — script, fogli di stile e iframe. Questi possono controllare l’intera pagina, quindi uno manomesso potrebbe riscrivere tutto. I browser lo bloccano. Questo è ciò che effettivamente rompe il layout, l’interattività o un intero widget incorporato dopo una migrazione.
• Contenuto misto passivo — immagini, audio e video. Questi non possono prendere il controllo della pagina, quindi storicamente i browser li hanno caricati ma hanno tolto il lucchetto e mostrato un avviso “non completamente sicuro”. Questo sta cambiando — i browser moderni li aggiornano o li bloccano sempre più spesso.

Una cosa che non è contenuto misto: un semplice link (<a href="http://…">) a una pagina HTTP. Quello ti porta semplicemente da un’altra parte; non carica un elemento non sicuro nella tua pagina sicura.

Come risolverlo

La soluzione è quasi sempre la stessa: far caricare la risorsa non sicura su HTTPS. Cambia http:// in https:// nel riferimento, oppure usa un percorso che non codifichi affatto il protocollo. La maggior parte delle volte la risorsa è già disponibile su HTTPS — qualcuno ha semplicemente lasciato un vecchio URL http:// in un template, un plugin o il database.

Se vuoi una rete di sicurezza per qualsiasi cosa ti sia sfuggita, puoi aggiungere una singola riga di configurazione — l’header upgrade-insecure-requests — che dice al browser di riscrivere silenziosamente le richieste di risorse http:// rimaste in https:// prima di inviarle. È un’ottima rete di sicurezza, ma non è un motivo per saltare la pulizia della vera fonte. Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

Vuoi il quadro completo — gli elenchi esatti di risorse che i browser bloccano, come rilevare il contenuto misto su larga scala con la console DevTools e i report CSP, le direttive upgrade-insecure-requests e block-all-mixed-content, perché il tuo CMS continua a reintrodurlo e come il contenuto misto interagisce con HSTS? Passa alla scheda Avanzate.

TL;DR — Il contenuto misto è una pagina HTTPS che carica una sotto-risorsa su HTTP. La tassonomia attuale browser/W3C lo classifica in contenuto aggiornabile e bloccabile; la vecchia suddivisione attivo/passivo (usata qui per valutare la portata dell’impatto) segue ancora quella divisione per la maggior parte dei tipi di risorse, con eccezioni — le immagini con CORS abilitato, i candidati srcset/picture e le richieste a host IP sono bloccabili anche se un semplice img src è aggiornabile. Attivo (script, fogli di stile, iframe, XMLHttpRequest/fetch e qualsiasi cosa il browser esegua) è bloccato — uno script manomesso può riscrivere la pagina — quindi è la regressione del giorno del lancio da correggere per prima. Passivo (immagini, audio, video) storicamente veniva caricato con un indicatore declassato e ora viene sempre più spesso aggiornato automaticamente o bloccato. I link di ancoraggio e altre navigazioni HTTP di livello superiore non sono contenuto misto; nemmeno i download non sicuri, che sono un confine correlato ma separato. Rilevalo su tre livelli — sorgente recuperata, stato renderizzato/runtime e sessioni utente reali — eseguendo il crawl del sito HTTPS, leggendo la console di Chrome DevTools (la dicitura esatta dipende da browser/versione), o raccogliendo le violazioni di Content-Security-Policy-Report-Only; correggilo confermando che un equivalente HTTPS funzioni davvero, poi puntando ogni sotto-risorsa a https:// (i percorsi relativi/protocollo-relativi vanno bene una volta verificati la proprietà e il comportamento dell’URL di base, non come default universale). Content-Security-Policy: upgrade-insecure-requests riscrive le richieste interessate di sotto-risorse http:// (incluse quelle cross-origin) a https:// prima che vengano inviate e prima che i controlli di contenuto misto/CSP vengano eseguiti — una rete, non un sostituto per correggere la sorgente, con nessun fallback HTTP se l’aggiornamento fallisce, e non aggiorna la navigazione di livello superiore verso origini di terze parti, quindi non sostituisce HSTS. Mettere la direttiva stessa in modalità di sola segnalazione non produce alcun effetto — monitora invece con una policy separata di sola segnalazione. I database CMS (fai backup e prova a secco qualsiasi sostituzione — una sostituzione ingenua di stringhe può corrompere dati serializzati), plugin, temi, service worker/cache e tag pubblicitari/analytics sono i recidivi ricorrenti — audita su larga scala, non pagina per pagina.

L’hub HTTPS introduce il contenuto misto come uno dei due modi di fallimento del giorno del lancio di una migrazione (l’altro sono i redirect). Questo è l’approfondimento a cui punta — i livelli esatti di risorse, lo stack di rilevamento, le direttive CSP e le ragioni operative per cui continua a ripresentarsi.

Cosa conta come contenuto misto — e cosa no

Il contenuto misto è definito con precisione: riguarda le sotto-risorse che la pagina carica, non i link che la pagina contiene. La definizione di Google: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (traduzione) «Una pagina ha contenuto misto quando il suo HTML iniziale viene caricato su una connessione HTTPS sicura, ma altre risorse (come immagini, video, fogli di stile e script) vengono caricate su una connessione HTTP non sicura.» Evidence for this claim Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Scope: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confidence: high · Verified: 2026-07-14 MDN: Mixed content

La trappola che rassicura falsamente le persone è il tag di ancoraggio. Un link <a href="http://…"> a una pagina HTTP non è contenuto misto — naviga a un nuovo documento; non carica una risorsa non sicura nella pagina sicura corrente. Questo vale per qualsiasi navigazione di livello superiore a una pagina HTTP, non solo per i clic sui link di ancoraggio.

Vale comunque la pena inviare link in uscita a destinazioni HTTPS. Con la moderna Referrer-Policy predefinita del browser (strict-origin-when-cross-origin), un clic da una pagina HTTPS a una destinazione HTTP fa cadere l’header Referer, il che può rovinare le analisi dei referral — ma quel comportamento è dipendente da policy e browser, non una regola universale: una pagina (o un proxy/CDN a monte) che imposta una Referrer-Policy più permissiva può comunque inviare un referrer su quel declassamento. Controlla la Referrer-Policy effettiva in vigore prima di affermare quanti dati di referral un dato sito perde — ma in ogni caso, questo è un problema separato dal contenuto misto, non contenuto misto stesso.

Attivo vs. passivo: la distinzione che definisce le tue priorità

La documentazione moderna dei browser e del W3C classifica i contenuti misti principalmente come aggiornabili rispetto a bloccabili — tipi di risorse che il browser ritenterà silenziosamente su HTTPS rispetto a quelli che rifiuta del tutto — piuttosto che la più vecchia divisione attivo/passivo. Attivo/passivo è ancora un’utile scorciatoia per perché i browser tracciano quella linea (quanto della pagina la risorsa potrebbe compromettere), ed è come l’explainer di Google stesso lo inquadra, quindi è mantenuto qui sotto come struttura di triage primaria — solo non trattarlo come la tassonomia ufficiale attuale quando devi ragionare su un tipo di risorsa specifico; vedi le eccezioni dopo le due liste.

I browser classificano i contenuti misti in base a quanto della pagina la risorsa insicura potrebbe compromettere. Google: “Active mixed content poses a greater threat than passive mixed content.” (traduzione) «I contenuti misti attivi rappresentano una minaccia maggiore rispetto ai contenuti misti passivi.» Quella singola frase dovrebbe guidare il tuo ordine di triage.

I contenuti misti attivi interagiscono con — e possono prendere il controllo di — l’intera pagina. Google li descrive come “scripts, stylesheets, iframes, and any other code the browser can download and execute.” (traduzione) «script, fogli di stile, iframe e qualsiasi altro codice che il browser può scaricare ed eseguire.» In pratica la lista attiva è:

• <script src="http://…"> — il caso peggiore; uno script intercettato può riscrivere l’intero DOM, esfiltrare dati dei moduli o iniettare contenuti.
• <link rel="stylesheet" href="http://…"> — i CSS possono nascondere, riposizionare o sovrapporre qualsiasi elemento, quindi sono trattati come attivi.
• <iframe src="http://…"> — un documento insicuro incorporato all’interno del tuo documento sicuro.
• XMLHttpRequest / fetch() verso http:// — dati insicuri su cui la pagina poi agisce.
• Web font, risorse <object>/<embed> e le varianti di <link> che richiamano contenuti eseguibili o che controllano il layout.

Poiché una risorsa attiva manomessa può riscrivere la pagina, “Most browsers already block this type of content by default to protect users.” (traduzione) «La maggior parte dei browser blocca già questo tipo di contenuto per impostazione predefinita per proteggere gli utenti.» Ecco perché i contenuti misti attivi sono ciò che visibilmente rompe le cose dopo una migrazione — un foglio di stile bloccato rimuove il tuo CSS, uno script bloccato uccide l’interattività, un iframe bloccato lascia un buco. Sistema prima gli attivi. È un bug funzionale, non solo un avviso di sicurezza.

Contenuti misti passivi (di visualizzazione) — Google: “including images, video, and audio” (traduzione) «inclusi immagini, video e audio» — “doesn’t interact with the rest of the page.” (traduzione) «non interagiscono con il resto della pagina.» Un’immagine intercettata può essere sostituita ma non può impossessarsi del documento. Quindi storicamente i browser la caricavano e semplicemente declassavano l’ indicatore: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (traduzione) «Fino a poco tempo fa, i contenuti misti passivi venivano caricati in tutti i browser, perché bloccarli avrebbe rotto molti siti web. Questo sta iniziando a cambiare.» La direzione di marcia nei browser è verso l’auto-aggiornamento delle risorse passive a HTTPS dove possibile e il blocco di ciò che non può essere aggiornato, quindi “passivo = innocuo” non è più un’ipotesi sicura su cui costruire.

Eccezioni che la divisione attivo/passivo non cattura

La linea aggiornabile/bloccabile ha diverse eccezioni che non seguono il modello generale “le immagini si aggiornano, gli script si bloccano” sopra — questi sono i casi che in pratica fanno inciampare le persone:

• Le richieste di immagini con CORS abilitato vengono forzate al fallimento, non aggiornate. Un normale <img src="http://…"> è aggiornabile, ma una richiesta di immagine effettuata con crossorigin impostato viene trattata diversamente dall’algoritmo dei contenuti misti e fallisce invece di aggiornarsi silenziosamente.
• I candidati srcset e <picture> sono bloccabili, non aggiornabili. La stessa immagine, richiesta tramite un meccanismo di immagini reattive invece di un semplice src, rientra nella categoria bloccabile — non dare per scontato che ogni riferimento a un’immagine si comporti allo stesso modo.
• Gli host con indirizzi IP sono bloccati, non aggiornati, anche per un tipo di risorsa altrimenti aggiornabile. Un riferimento come http://203.0.113.5/logo.png non riceve il trattamento di aggiornamento automatico che avrebbe un equivalente ospitato su un dominio.
• I contesti annidati e i worker sono inclusi. I controlli dei contenuti misti si applicano anche all’interno di iframe e di service/shared worker, non solo al documento principale — un
• Le origini locali e di loopback hanno le loro sfumature. localhost, gli indirizzi di loopback e i contesti file:// sono “origini potenzialmente affidabili” secondo la specifica anche senza TLS, quindi una semplice euristica HTTP-vs-HTTPS non si mappa chiaramente sugli ambienti di sviluppo locale.
• I download non sicuri sono un confine correlato ma separato. Un download avviato da una pagina sicura tramite http:// è un rischio reale, ma è governato dalla propria gestione della sicurezza dei download, non dalle regole sui contenuti misti dei sotto-risorse in questa sezione.
• La navigazione HTTP di livello superiore non è ancora contenuto misto, incluso il caso del collegamento di ancoraggio sopra — questa è una proprietà della navigazione, non di una sotto-risorsa caricata, per quante di queste altre eccezioni si applichino.

Rilevare i contenuti misti — l’intero stack

Non esiste un unico pulsante, e ogni livello sottostante risponde a una domanda diversa — un risultato pulito a un livello non esclude gli altri. Diagnostica sorgente recuperata (ciò a cui l’HTML grezzo fa effettivamente riferimento), stato renderizzato/a runtime (ciò che il browser richiede una volta che ha analizzato la pagina ed eseguito i suoi script) e sessioni utente reali (ciò che accade per un visitatore dietro un banner di consenso, un reindirizzamento geografico, una schermata di accesso o un tag di terze parti che si attiva solo in condizioni specifiche) separatamente. Stratifica questi livelli da “una pagina” a “intero sito”:

1. La console di Chrome DevTools (stato renderizzato/a runtime). Carica la pagina HTTPS e apri la console. I contenuti attivi misti bloccati registrano un messaggio del tipo “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (traduzione) «Contenuto misto: la pagina … è stata caricata tramite HTTPS, ma ha richiesto una risorsa non sicura … Questa richiesta è stata bloccata; il contenuto deve essere fornito tramite HTTPS.» Il contenuto passivo che viene caricato registra un avviso piuttosto che un blocco. Il pannello Security (o la scheda Issues) li raggruppa per pagina. Veloce per controlli rapidi e per confermare una correzione specifica — ma tratta la formulazione esatta del messaggio, il layout del pannello e persino quali tipi di risorse vengono bloccati come specifici del browser e della versione; questo è stato confermato con Chrome a partire da luglio 2026 e dovresti verificare la formulazione attuale sul browser/versione effettivo che stai diagnosticando piuttosto che citarla come stringa UI fissa, e aspettati che Firefox, Safari ed Edge differiscano.

2. Un crawler del sito (sorgente recuperata, su larga scala). DevTools è per pagina; una scansione è a livello di sito. Ahrefs Site Audit e Screaming Frog segnalano entrambi le pagine che fanno riferimento a sotto-risorse http:// su un sito HTTPS — l’unico modo realistico per trovare contenuti misti su migliaia di URL. Questo è lo strumento principale per un audit, ma sta comunque leggendo la sorgente: una scansione che passa pulita non prova che la pagina renderizzata o una sessione reale siano pulite anche loro — registra quale browser/strumento/versione ha prodotto un dato risultato piuttosto che riportare un singolo pass/fail non qualificato.

3. Segnalazione delle violazioni CSP (sessioni utente reali). Puoi fare in modo che i browser dei visitatori reali ti segnalino i contenuti misti, il che cattura risorse che si caricano solo su determinate pagine, per determinati utenti, in determinati stati di consenso, o da tag di terze parti che non controlli — il livello che né una scansione né un singolo controllo DevTools possono raggiungere. web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (traduzione) «Puoi usare la Content Security Policy per raccogliere segnalazioni di contenuto misto sul tuo sito. Per abilitare questa funzionalità, imposta la direttiva Content-Security-Policy-Report-Only aggiungendola come header di risposta del sito.» La modalità di sola segnalazione segnala le violazioni senza applicare la policy, quindi puoi misurare il problema in produzione prima di attivare il blocco. (Il meccanismo è l’header moderno report-to / Reporting-Endpoints, o il più vecchio report-uri. Nota che questa è una policy diversa e di scopo generale, configurata per la sola segnalazione, rispetto a upgrade-insecure-requests stesso — mettere quella specifica direttiva in modalità di sola segnalazione non funziona, come spiegato sotto.)

Usa tutti e tre: DevTools per verificare una pagina renderizzata, un crawler per inventariare il sorgente recuperato, i report CSP per catturare la coda lunga delle sessioni reali che si manifesta solo in produzione. Una scansione che passa è una prova sul sorgente, non una garanzia che ogni stato di consenso, variante ad-tech, ramo di personalizzazione o worker sia pulito.

Correggere alla fonte

La vera correzione inizia prima di toccare un singolo riferimento: verifica che l’equivalente HTTPS effettivamente esista, presenti un certificato valido e restituisca il contenuto che ti aspetti — non dare per scontato che cambiare lo schema sia sicuro solo perché il dominio risolve. Una volta confermato, ogni riferimento a sotto-risorse dovrebbe risolvere su HTTPS. Le opzioni sotto sono in ordine approssimativo di preferenza, ma ognuna dipende ancora dalla titolarità e dal contesto, non solo dalla stringa che digiti:

• URL HTTPS assoluti — cambia http://cdn.example.com/app.js in https://cdn.example.com/app.js. Esplicito e inequivocabile; il default più sicuro quando non sei certo del contesto di servizio sotto.
• Percorsi relativi alla radice o relativi — per risorse che possiedi sullo stesso sito, /assets/app.js eredita automaticamente lo schema della pagina. La guida HTTPS di Google: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (traduzione) «Assicurati che gli URL interni e quelli esterni non dipendano da un protocollo specifico. Usa percorsi relativi oppure ometti il protocollo, come in //example.com/something.js.» Tratta questo come condizionale, non come raccomandazione universale: vale solo una volta che hai confermato di possedere effettivamente la risorsa (un percorso relativo a una risorsa di terze parti non ha senso), che l’URL base reale della pagina risolva come ti aspetti (un tag <base>, un percorso proxy, o un contesto embedded/AMP possono cambiare cosa significa “relativo”), e che nulla a valle ricostruisca l’URL in un modo che reintroduce http:// — ad esempio, codice lato client che costruisce un URL da window.location o un valore assoluto memorizzato.
• URL relativi al protocollo (//example.com/something.js) funzionano ancora, ma non sono la correzione universale preferita — condizionali agli stessi controlli di titolarità/URL base sopra, non solo per abitudine. Su un web tutto HTTPS, un https:// esplicito è di solito più chiaro ed evita sorprese se il file viene mai aperto da un contesto non HTTP; ricorri al protocollo relativo solo dove hai un motivo specifico per non hardcodare lo schema.

Su larga scala non si modificano quasi mai i template uno per uno — ma non eseguire nemmeno una sostituzione di stringhe nel database senza protezione in produzione. http://yourdomain → https://yourdomain sembra una semplice operazione di trova-e-sostituisci, e per i campi di testo semplice spesso è sicura, ma i contenuti CMS possono essere serializzati o strutturati (array serializzati PHP, blob JSON, dati dell’editor a blocchi) dove una sostituzione ingenua di sottostringhe corrompe il record invece di ripararlo. Usa strumenti che comprendono il formato di serializzazione, fai un backup del database prima, e prova a secco la sostituzione così puoi rivedere le righe interessate prima di applicarla. Poi correggi la manciata di file di template/config che generano gli URL; il crawler e i report CSP ripuliscono i casi residui.

upgrade-insecure-requests: la rete di sicurezza (e i suoi limiti)

La protezione proattiva è una direttiva Content-Security-Policy. web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (traduzione) «La direttiva CSP upgrade-insecure-requests indica al browser di aggiornare gli URL non sicuri prima di effettuare richieste di rete.» Imposta l’header:

Content-Security-Policy: upgrade-insecure-requests

Secondo MDN, “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (traduzione) «istruisce gli user agent a trattare tutti gli URL non sicuri di un sito, cioè quelli serviti tramite HTTP, come se fossero stati sostituiti con URL sicuri, cioè serviti tramite HTTPS.» Concretamente, MDN dice che aggiorna: “requests to load resources (such as images, scripts, or fonts),” (traduzione) «le richieste di caricamento di risorse, come immagini, script o font», “navigation requests (such as link targets) which are same-origin with the document,” (traduzione) «le richieste di navigazione, come le destinazioni dei link, che hanno la stessa origine del documento», “navigation requests in nested browsing contexts, such as iframes,” (traduzione) «le richieste di navigazione in contesti di navigazione annidati, come gli iframe», e “form submissions.” (traduzione) «gli invii di moduli.» Evidence for this claim The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Scope: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confidence: high · Verified: 2026-07-14 MDN: CSP upgrade-insecure-requests

Due dettagli operativi contano oltre quella citazione. Primo, l’aggiornamento delle sotto-risorse non è limitato alle richieste same-origin — è l’aggiornamento della navigazione che è solo same-origin secondo la citazione sopra; le normali richieste di sotto-risorse vengono riscritte anche tra origini diverse, quindi uno script ospitato su CDN o un font di terze parti viene aggiornato, non solo le risorse dello stesso sito. Secondo, la riscrittura avviene prima che i controlli di mixed-content e CSP del browser valutino la richiesta, motivo per cui una risorsa che altrimenti verrebbe bloccata del tutto come contenuto misto può caricarsi correttamente una volta aggiornata — l’aggiornamento previene il blocco.

Tre limiti che non devi ignorare:

• Non aggiorna la navigazione di primo livello di terze parti. MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” (traduzione) «Tuttavia, le richieste di navigazione di primo livello la cui destinazione ha un’origine diversa non verranno aggiornate.» Per questo motivo, non è esplicitamente un sostituto di HSTS: “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (traduzione) «La direttiva upgrade-insecure-requests non garantisce che gli utenti che visitano il sito tramite link su siti di terze parti vengano aggiornati a HTTPS per la navigazione di primo livello e pertanto non sostituisce l’header Strict-Transport-Security (HSTS).» (Maggiori dettagli su questa distinzione sotto.)
• È una rete, non una soluzione, e non fa fallback. Se la risorsa non è realmente disponibile su HTTPS, la richiesta aggiornata fallisce semplicemente — non torna alla versione originale http://. Pulire la fonte resta il compito; la direttiva copre ciò che ti è sfuggito, non ciò che è realmente rotto.
• La modalità di sola segnalazione non esegue l’aggiornamento e non produce alcun effetto. Mettere upgrade-insecure-requests dentro un header Content-Security-Policy-Report-Only viene ignorato dal browser: nulla viene riscritto, e nulla viene segnalato per questo. Se vuoi visibilità su cosa l’aggiornamento influenzerebbe prima di applicarlo, esegui una policy separata e generica di sola segnalazione che segnali le destinazioni http:// non consentite (lo stesso approccio default-src https: in modalità di sola segnalazione usato per il rilevamento sopra) — non puoi ottenere quella visibilità rendendo la stessa direttiva upgrade-insecure-requests in modalità di sola segnalazione.

block-all-mixed-content — per lo più storico

Esiste una direttiva complementare, block-all-mixed-content, che — secondo MDN — “prevents loading any assets over HTTP when the page uses HTTPS,” (traduzione) «impedisce il caricamento di qualsiasi risorsa tramite HTTP quando la pagina usa HTTPS», inclusi “both blockable and upgradable mixed content,” (traduzione) «sia il contenuto misto bloccabile sia quello aggiornabile», e si applica anche agli iframe. In pratica è stata superata. MDN la contrassegna come deprecata e “obsolete in the specification,” (traduzione) «obsoleta nella specifica», notando: “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (traduzione) «Il contenuto che non viene bloccato ora viene sempre aggiornato a una connessione sicura, quindi questa direttiva non è necessaria.» Ricorri a upgrade-insecure-requests; tratta block-all-mixed-content come legacy che potresti ereditare, non qualcosa da implementare ex novo. Se invii già upgrade-insecure-requests, block-all-mixed-content non ha più nulla da fare per le richieste aggiornate — la riscrittura dell’upgrade avviene prima, quindi quando un controllo block-all dovrebbe essere eseguito, la richiesta è già stata aggiornata (o è già fallita). Non è solo legacy; è ridondante ovunque UIR sia già implementato.

Perché il tuo CMS continua a reintrodurlo

Il contenuto misto non è una pulizia una tantum — si ripresenta, perché diversi sistemi re-iniettano silenziosamente URL http:// dopo che pensi di aver finito:

• Il database dei contenuti. In WordPress, Drupal e nella maggior parte dei CMS, gli editor incollano immagini ed embed con URL assoluti http:// direttamente nei corpi dei post. Questi vivono nel database, non in un template, quindi una correzione a livello di codice non li tocca mai — da qui la ricerca e sostituzione nel DB.
• Temi e plugin. Un tema o plugin che codifica un URL di risorsa http:// (un font, uno script, un’immagine di sfondo) reintroduce contenuto misto su ogni pagina che renderizza, e un aggiornamento del plugin può riportarlo dopo che l’hai ripulito.
• Ad tech, analytics e tag di terze parti. I tag manager, le reti pubblicitarie, i widget di chat e gli snippet di analytics caricano le proprie sotto-risorse — e se il tag di un fornitore chiama ancora http://, è contenuto misto che non puoi correggere nel tuo codice. Questo è esattamente ciò a cui serve la coda lunga dei report CSP; la soluzione duratura è spingere il fornitore a servire su HTTPS (o rimuovere il tag). Se un fornitore non ha un endpoint HTTPS funzionante, le scelte durature sono le stesse tre: convincerli a sistemarlo, sostituire la dipendenza, o rimuoverla — non esiste una quarta opzione che mantenga la versione insicura in esecuzione in modo sicuro.
• Service worker e cache. Un service worker può memorizzare nella cache una risposta (o la richiesta stessa) che punta ancora a http://, e continuerà a servire quel riferimento obsoleto nelle visite ripetute anche dopo che correggi la fonte. Riproduci una correzione sospetta in una sessione in incognito/senza cache prima di concludere che non ha funzionato, e assicurati che un deploy che modifica gli URL delle risorse aggiorni anche la versione del service worker/cache così che le voci obsolete vengano eliminate piuttosto che riprodotte.
• URL http:// codificati direttamente in vecchi contenuti e template email/stampa che vengono riutilizzati.

Il punto operativo: integra il rilevamento in un audit ricorrente (crawler + report CSP), non in una checklist per il giorno del lancio che esegui una volta sola.

Come il contenuto misto interagisce con HSTS

Il contenuto misto e HSTS risolvono problemi adiacenti ma diversi, e confonderli è un errore comune:

• upgrade-insecure-requests corregge le sotto-risorse che la tua pagina sicura richiede — aggiorna le immagini/script/iframe che la pagina carica.
• HSTS (Strict-Transport-Security) forza la navigazione di primo livello verso il tuo sito su HTTPS — anche la primissima richiesta, prima che scatti qualsiasi reindirizzamento — e difende contro lo stripping SSL. Google presenta HSTS come un modo per “avoid the cost of the 301 redirect” (traduzione) «evitare il costo del reindirizzamento 301» e per “defeat attacks like SSL Stripping.” (traduzione) «sconfiggere attacchi come lo SSL Stripping.»

Non si sostituiscono a vicenda. Come spiega MDN, upgrade-insecure-requests “will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (traduzione) «non garantirà che gli utenti che visitano il sito tramite link su siti di terze parti vengano aggiornati a HTTPS per la navigazione di primo livello e quindi non sostituisce l’header Strict-Transport-Security (HSTS).» Una configurazione completamente protetta usa entrambi: upgrade-insecure-requests (o URL di origine puliti) così che la pagina sicura non abbia carico insicuro, e HSTS così che nessuno raggiunga il sito via HTTP in primo luogo. E vale sempre la solita avvertenza sull’HSTS — Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors,” (traduzione) «Non abilitare HSTS finché non sei certo che il funzionamento del sito sia abbastanza robusto da evitare di distribuire HTTPS con errori di convalida del certificato», e il preload è quasi una porta a senso unico.

Il contenuto misto danneggia direttamente la SEO?

Inizia con gli effetti diretti, perché sono quelli che controlli davvero: il contenuto misto è prima di tutto un problema di sicurezza e funzionale. Il contenuto misto attivo bloccato rompe del tutto il rendering e l’interattività — un foglio di stile o uno script mancante è una vera regressione indipendentemente da ciò che ne pensa un motore di ricerca. Questo è motivo sufficiente per risolverlo prima di pensare alle classifiche.

Le conseguenze SEO sono reali ma condizionali, non dirette o garantite. Le attuali linee guida ufficiali di Google non stabiliscono che la correzione del contenuto misto sia un vantaggio diretto per il ranking — il segnale di ranking HTTPS stesso è basato sullo schema (se l’URL inizia con https://), non un controllo di pulizia delle sotto-risorse, quindi un’immagine insicura isolata non costa da sola “il segnale HTTPS”. Ma gli effetti a valle possono comunque manifestarsi a seconda di ciò che è effettivamente rotto: se Googlebot esegue il rendering di una pagina il cui CSS o JS è stato bloccato come contenuto misto, potrebbe indicizzare una versione rotta o incompleta; un indicatore di sicurezza declassato può danneggiare la fiducia degli utenti, il coinvolgimento e le conversioni anche senza alcun cambiamento nel ranking; e la preferenza generale di Google per i canonical HTTPS è a sua volta condizionale — certificati non validi, dipendenze insicure, redirect HTTPS-a-HTTP o segnali canonical contrastanti altrove nella pagina possono tutti cambiare quale URL viene scelto, indipendentemente dal contenuto misto specifico. Tratta gli effetti su rendering, indicizzazione, canonicalizzazione e analisi come cose da verificare sulle tue pagine, non come risultati universali da promettere — e correggi il contenuto misto per motivi di sicurezza e funzionalità prima di tutto.

Questo si inserisce nel più ampio argomento HTTPS per la SEO, che copre il playbook di migrazione, il peso del segnale di ranking e l’HSTS in dettaglio; se stai anche debugando il certificato stesso (errori di catena, scadenza, DV/OV/EV), quello è un approfondimento correlato.

Riepilogo AI

Una sintesi della versione Advanced:

• Contenuto misto = una pagina HTTPS che carica una sotto-risorsa tramite HTTP. Riguarda risorse che la pagina carica, non i link che contiene — un anchor a una pagina HTTP (o qualsiasi navigazione HTTP di livello superiore) non è contenuto misto, e nemmeno un download non sicuro (un confine correlato ma separato).
• La tassonomia attuale è aggiornabile/bloccabile; attivo/passivo è il quadro di blast-radius più vecchio ma ancora utile. Attivo (script, fogli di stile, iframe, XMLHttpRequest/fetch — qualsiasi cosa il browser esegue) è bloccato perché uno script manomesso può riscrivere la pagina; è la regressione del giorno del lancio, sistemalo per primo. Passivo (immagini, audio, video) storicamente caricato con un lucchetto degradato e ora sempre più auto-aggiornato o bloccato. Eccezioni al modello generale: le richieste di immagini abilitate a CORS vengono forzate a fallire piuttosto che aggiornate, i candidati srcset/<picture> sono bloccabili (non aggiornabili) come il semplice img src, gli host con indirizzi IP sono bloccati piuttosto che aggiornati, e i contesti/worker annidati e le origini locali/loopback hanno le loro sfumature.
• Rileva su tre livelli, non uno: sorgente recuperata (un crawler come Ahrefs Site Audit o Screaming Frog, a livello di sito), stato renderizzato/runtime (la console di Chrome DevTools/pannello Sicurezza, per pagina — la dicitura esatta è specifica del browser/versione, confermata contro Chrome a partire da 2026-07), e sessioni utente reali (report di violazione Content-Security-Policy-Report-Only, la coda lunga di produzione inclusi tag di terze parti e risorse soggette a consenso). Un risultato pulito a un livello non cancella gli altri.
• Sistema alla fonte, dopo aver verificato che l’equivalente HTTPS funzioni davvero: punta ogni sotto-risorsa a https://; i percorsi relativi/protocollo-relativi vanno bene solo dopo aver verificato la proprietà e il comportamento reale dell’URL di base della pagina, non un default. Su larga scala, fai un backup del database e prova a secco qualsiasi sostituzione — una sostituzione ingenua di stringhe può corrompere dati CMS serializzati/strutturati — poi sistema i restanti file di template/config. Fai attenzione a service worker/cache che riproducono riferimenti http:// obsoleti dopo che la fonte è stata sistemata.
• upgrade-insecure-requests (un header CSP) riscrive le richieste di sotto-risorse http:// in scope — incluse quelle cross-origin — a https:// prima che vengano inviate e prima che i controlli di contenuto misto/CSP vengano eseguiti, una rete di sicurezza senza fallback HTTP se l’aggiornamento fallisce. Non aggiorna la navigazione di livello superiore verso origini di terze parti, quindi non è un sostituto per HSTS, e mettere la direttiva stessa in modalità di sola segnalazione non produce effetti — monitora invece con una policy separata configurata per la sola segnalazione.
• block-all-mixed-content è deprecato/obsoleto, e ridondante una volta che upgrade-insecure-requests è implementato (l’aggiornamento viene eseguito prima, quindi block-all non ha nulla da bloccare).
• Si ripresenta perché il database CMS, temi/plugin, service worker/cache, e tag pubblicitari/analitici continuano a reintrodurre URL http:// — fai audit su base programmata, non una volta sola.
• L’impatto SEO è condizionale, non diretto: le attuali linee guida di Google non stabiliscono un boost diretto del ranking dalla correzione del contenuto misto, e il segnale HTTPS è basato sullo schema. Ma le risorse attive bloccate possono far sì che Googlebot renda/indicizzi una pagina rotta, il downgrade del lucchetto costa fiducia, e la preferenza di Google per il canonico HTTPS è essa stessa condizionata a cose come la validità del certificato e segnali contrastanti — non una garanzia legata specificamente al contenuto misto.

Documentazione ufficiale

Documentazione di fonti primarie da Google e dai team di browser/standard.

Google / web.dev

• Che cos’è il contenuto misto? — la definizione e la distinzione tra attivo e passivo con il comportamento del browser.
• Correggere il contenuto misto — come trovarlo, correggere gli URL delle sotto-risorse, upgrade-insecure-requests e il reporting CSP.
• Abilitare HTTPS sui tuoi server — URL relativi/relativi al protocollo, la nota sull’<iframe> HTTP e le linee guida HSTS.
• Prevenire il contenuto misto è una parte delle linee guida HTTPS di Google — il playbook circostante per lo spostamento/migrazione del sito in cui si inseriscono le correzioni del contenuto misto.

MDN / standard

• CSP: upgrade-insecure-requests — cosa aggiorna, cosa non aggiorna e perché non sostituisce HSTS.
• CSP: block-all-mixed-content — la direttiva di blocco deprecata/obsoleta.
• MDN — Contenuto misto — il riferimento sul comportamento del browser per i contenuti bloccabili vs. aggiornabili.
• Content Security Policy (CSP) — l’header in cui vivono queste direttive, incluso il reporting.

Citazioni dalla fonte

Definizioni ufficiali dalle documentazioni di Google web.dev e MDN. Ogni collegamento è un collegamento profondo che salta al passaggio citato dove la piattaforma lo supporta.

Google / web.dev — cos’è il contenuto misto

• “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (traduzione) «Una pagina ha contenuto misto quando il suo HTML iniziale viene caricato su una connessione HTTPS sicura, ma altre risorse (come immagini, video, fogli di stile e script) vengono caricate su una connessione HTTP non sicura.» Fonte
• “Active mixed content poses a greater threat than passive mixed content.” (traduzione) «Il contenuto misto attivo rappresenta una minaccia maggiore rispetto al contenuto misto passivo.» Fonte
• Il contenuto misto attivo “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (traduzione) «include script, fogli di stile, iframe e qualsiasi altro codice che il browser può scaricare ed eseguire», e “Most browsers already block this type of content by default to protect users.” (traduzione) «La maggior parte dei browser blocca già questo tipo di contenuto per impostazione predefinita per proteggere gli utenti.» Fonte
• Il contenuto misto passivo, “including images, video, and audio,” (traduzione) «inclusi immagini, video e audio», “doesn’t interact with the rest of the page.” (traduzione) «non interagisce con il resto della pagina.» E: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (traduzione) «Fino a poco tempo fa, il contenuto misto passivo veniva caricato in tutti i browser, perché bloccarlo avrebbe rotto molti siti web. Questo sta iniziando a cambiare.» Fonte

Google / web.dev — rilevamento e correzione

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (traduzione) «Puoi usare la content security policy per raccogliere report sul contenuto misto sul tuo sito. Per abilitare questa funzionalità, imposta la direttiva Content-Security-Policy-Report-Only aggiungendola come header di risposta per il tuo sito.» Fonte
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (traduzione) «La direttiva CSP upgrade-insecure-requests istruisce il browser ad aggiornare gli URL non sicuri prima di effettuare richieste di rete.» Fonte
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (traduzione) «Assicurati che gli URL intrasito e gli URL esterni non dipendano da un protocollo specifico. Usa percorsi relativi o ometti il protocollo come in //example.com/something.js.» Fonte

MDN — upgrade-insecure-requests e i suoi limiti

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (traduzione) «La direttiva upgrade-insecure-requests della HTTP Content-Security-Policy (CSP) istruisce gli user agent a trattare tutti gli URL non sicuri di un sito (quelli serviti su HTTP) come se fossero stati sostituiti con URL sicuri (quelli serviti su HTTPS).» Source
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” (traduzione) «Tuttavia, le richieste di navigazione di primo livello la cui destinazione è un’origine diversa non verranno aggiornate.» Source
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (traduzione) «La direttiva upgrade-insecure-requests non garantirà che gli utenti che visitano il tuo sito tramite link su siti di terze parti vengano aggiornati a HTTPS per la navigazione di primo livello e quindi non sostituisce l’header Strict-Transport-Security (HSTS).» Source

MDN — block-all-mixed-content è legacy

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” (traduzione) «La direttiva block-all-mixed-content della HTTP Content-Security-Policy (CSP) impedisce il caricamento di qualsiasi risorsa tramite HTTP quando la pagina usa HTTPS.» Ma è contrassegnata come deprecata e “obsolete in the specification,” (traduzione) «obsoleta nella specifica», perché “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (traduzione) «Il contenuto che non viene bloccato ora viene sempre aggiornato a una connessione sicura, quindi questa direttiva non è necessaria.» Source

Checklist per i contenuti misti

Esegui questa operazione durante e dopo una migrazione HTTP→HTTPS, poi su base ricorrente:

Trovarlo

• Caricato i template chiave (home, prodotto, articolo, checkout) su HTTPS con la console di Chrome DevTools aperta e annotato ogni messaggio “Mixed Content”.
• Eseguito un crawl completo (Ahrefs Site Audit o Screaming Frog) ed estratto l’elenco delle pagine che fanno riferimento a sotto-risorse http://.
• Impostato Content-Security-Policy-Report-Only con un endpoint di reporting per intercettare la coda lunga di produzione (per utente, per pagina e tag di terze parti).

Ripararlo (attivo prima)

• Tutti i riferimenti attivi riparati: <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest, font — questi sono bloccati, quindi rompono la pagina.
• Tutti i riferimenti passivi riparati: <img>, <audio>, <video> e i loro URL <source>/poster.
• Sostituzione nel database del CMS (http://yourdomain → https://yourdomain) per contenuti incollati — con backup, prova a secco con strumenti consapevoli dell’applicazione, non una sostituzione di stringhe grezza su campi serializzati/strutturati.
• URL di risorse http:// codificati direttamente nel tema/plugin trovati e corretti.
• Voci service worker/cache riprodotte in una sessione senza cache e la versione della cache/service worker incrementata così che i riferimenti http:// obsoleti non vengano riprodotti.
• Tag di terze parti (annunci, analytics, chat, embed) confermati caricati su HTTPS — oppure il fornitore è stato sollecitato o il tag è stato rimosso.

Backstop e verifica

• Header Content-Security-Policy: upgrade-insecure-requests impostato come rete di sicurezza (comprendendo che non sostituisce HSTS).
• Ricrawlerizzato e ricontrollata la console — zero risorse attive bloccate, lucchetto pulito sulle pagine controllate.
• Rilevamento dei contenuti misti aggiunto all’audit ricorrente, non solo alla checklist di lancio (gli aggiornamenti dei plugin e i nuovi contenuti lo reintroducono).

Quale correzione serve per questo caso di contenuti misti?

Procedi a ritroso dal sintomo.

La cosa insicura è una risorsa che la pagina carica, o un link che la pagina contiene?

• Un link (<a href="http://…">) → non è contenuto misto. Lascialo (opzionalmente puntalo su HTTPS per la pulizia dei dati di referral). Fermati qui.
• Una risorsa caricata (script, style, iframe, immagine, font, media, fetch) → continua.

La risorsa è disponibile su HTTPS?

• Sì, e l’hai verificato (certificato valido, restituisce il contenuto previsto) → cambia il riferimento a https:// (l’impostazione predefinita sicura), o un percorso relativo / relativo al protocollo solo se possiedi la risorsa e hai controllato il comportamento dell’URL di base della pagina. Questa è la vera soluzione. Fatto.
• No / non sono sicuro → è di prima parte (una tua risorsa)?
  • Di prima parte → servila su HTTPS (è il tuo server; puoi farlo). Poi correggi il riferimento come sopra.
  • Di terze parti (un tag del fornitore, un annuncio, un embed) → chiedi al fornitore un endpoint HTTPS; se non ce l’ha, sostituisci o rimuovi il tag. upgrade-insecure-requests tenterà di aggiornarlo, ma se il fornitore non ha una versione HTTPS la richiesta aggiornata semplicemente fallisce.

È attivo o passivo?

• Attivo (script / stylesheet / iframe / fetch / font) → priorità massima — è bloccato, quindi la pagina è funzionalmente rotta finché non lo sistemi.
• Passivo (immagine / audio / video) → sistimalo anche questo, ma è meno urgente (declassamento del lucchetto / possibile blocco futuro, non una rottura immediata).

Vuoi una rete di sicurezza per ciò che ti è sfuggito?

• Imposta Content-Security-Policy: upgrade-insecure-requests. Ricorda: rete, non sostituto — e non copre la navigazione di terze parti a livello di pagina principale, quindi non è un sostituto di HSTS.

Devi anche forzare la pagina principale su HTTPS per i referral di prima volta / di terze parti?

• Questo è HSTS, un controllo separato. Aggiungi Strict-Transport-Security — ma solo quando la tua operazione sui certificati è a prova di bomba, perché HSTS (soprattutto il preload) è quasi una porta a senso unico.

I modelli mentali

1. Risorse, non link. Il contenuto misto riguarda ciò che la pagina sicura carica, mai dove collega. Se non riesci a decidere se qualcosa conta, chiediti: il browser lo recupera per costruire la pagina corrente? Sì → possibile contenuto misto. Mi porta solo a un’altra pagina → non è contenuto misto.

2. Triage in base a ciò che fa il browser, non alla gravità in astratto. Attivo (script, stili, iframe) è bloccato → è un bug funzionale, sistimalo prima. Passivo (immagini, media) è avvisato/aggiornato → sistimalo dopo. Il comportamento del browser stesso è la tua coda di priorità.

3. Il rilevamento è un imbuto: verifica → inventario → cattura la coda. Console DevTools (una pagina, esatta), crawler (intero sito, la maggior parte), report CSP (produzione, terze parti, coda lunga per utente). Nessun singolo strumento vede tutti e tre.

4. Sistima la fonte; rete per il resto. Pulisci gli URL effettivi — DB, template, tag. Poi aggiungi upgrade-insecure-requests come rete di sicurezza per ciò che sfugge. La direttiva è assicurazione, non riparazione.

5. Due diversi lavori di “forza HTTPS”, due diversi strumenti. upgrade-insecure-requests aggiorna le sotto-risorse che la tua pagina sicura richiede. HSTS forza la navigazione a livello di pagina principale verso il tuo sito su HTTPS. Non si sovrappongono e uno non sostituisce mai l’altro — un sito robusto usa entrambi.

6. È un audit ricorrente, non un compito una tantum. Il database CMS, gli aggiornamenti di plugin/temi e i tag di terze parti continuano a reintrodurre http://. Tratta il rilevamento come una scansione programmata, o torna silenziosamente.

Anti-pattern del contenuto misto

Errori che lasciano contenuto insicuro attivo — o lo mascherano invece di sistemarlo.

• Trattare upgrade-insecure-requests come la soluzione. È una rete. Se la risorsa non ha una versione HTTPS, la richiesta aggiornata fallisce e hai nascosto una dipendenza rotta invece di risolverla. Pulisci gli URL sorgente; usa la direttiva per la coda.
• Supporre che un deploy del codice abbia ripulito il database. In un CMS, la maggior parte degli URL di immagini ed embed http:// vive in righe di contenuto, non nei template. Una correzione del template lascia ogni vecchio post misto. Esegui la ricerca e sostituzione nel database.
• Sottovalutare il contenuto misto attivo perché “è solo un avviso”. Non lo è — l’attivo è bloccato. Un foglio di stile o uno script bloccato è un’interruzione funzionale, non un fastidio estetico.
• Controllare a campione la homepage e considerare il lavoro finito. Il contenuto misto si nasconde nelle pagine prodotto, nei vecchi post del blog e nei percorsi che solo alcuni utenti visitano. Scansiona l’intero sito e usa i report CSP per ciò che la scansione non può raggiungere.
• Ignorare i tag di terze parti. Un fornitore di annunci, analytics o chat che chiama ancora http:// è contenuto misto che non puoi correggere nel tuo repository. Inseguirlo nel tuo codice per sempre è uno sforzo sprecato — spingi il fornitore o rimuovi il tag.
• Usare block-all-mixed-content su una nuova build. È deprecato e obsoleto. Usa invece upgrade-insecure-requests.
• Confondere upgrade-insecure-requests con HSTS. Uno aggiorna le sotto-risorse; l’altro forza HTTPS a livello top-level e difende dallo stripping SSL. Implementarne uno e supporre di aver coperto l’altro lascia una vera lacuna.
• Lasciare il rilevamento fuori dall’audit ricorrente. Correggerlo una volta e non controllare mai più garantisce che un aggiornamento di plugin o un’immagine http:// incollata lo riporti inosservato.

Contenuto misto — cheat sheet

Attivo vs. passivo

Stack di rilevamento

Le direttive CSP

Non-confondere-questi

Correzione in una riga (CMS): ricerca e sostituzione nel database http://yourdomain → https://yourdomain, poi correggi template/plugin, poi imposta upgrade-insecure-requests.

Trova contenuto misto — snippet

1. Scansiona una pagina dalla riga di comando

Prendi una pagina e segnala qualsiasi sotto-risorsa src/href insicura rimasta nell’HTML.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Questo vede solo l’HTML grezzo — le risorse iniettate da JavaScript non appariranno, motivo per cui usi anche DevTools e un crawler reale.

2. Console di Chrome DevTools — elenca le risorse non sicure sulla pagina renderizzata

Incolla nella console sulla pagina HTTPS per catturare anche i riferimenti inseriti da JS:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

Il browser registra autonomamente anche il contenuto misto attivo bloccato con il messaggio “Mixed Content: … This request has been blocked; the content must be served over HTTPS.” (traduzione) «Contenuto misto: … Questa richiesta è stata bloccata; il contenuto deve essere fornito tramite HTTPS.» — leggi prima questi messaggi.

3. Bookmarklet — dump della console con un clic

Salva come segnalibro; cliccalo su qualsiasi pagina HTTPS per registrare nella console i suoi riferimenti http://:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. Attiva il reporting CSP (rileva in produzione)

Aggiungi un’intestazione di sola segnalazione in modo che i browser dei visitatori reali ti segnalino le violazioni — inclusi i tag di terze parti e le pagine che il tuo crawl non vede:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Solo-report riporta senza applicare, così puoi valutare il problema in sicurezza prima di attivare upgrade-insecure-requests o l’applicazione. (L’equivalente moderno usa report-to con un’intestazione Reporting-Endpoints.)

5. L’intestazione di sicurezza (una volta risolta la fonte)

Content-Security-Policy: upgrade-insecure-requests

Ricorda che non aggiorna la navigazione di primo livello di terze parti e non è un sostituto di HSTS.

SOP ricorrente per l’audit del contenuto misto

Esegui questo dopo i lanci HTTPS, le release di CMS o temi, le modifiche al tag manager e con una cadenza regolare per i siti i cui contenuti cambiano frequentemente.

1. Crawla le pagine HTTPS in modalità grezza e renderizzata. Esporta gli URL non sicuri da src, srcset, fogli di stile, iframe, media e richieste fetch/XHR; i normali link di ancoraggio HTTP non sono contenuto misto.
2. Raccogli prove dal browser. Rivedi DevTools su template rappresentativi e usa Content-Security-Policy-Report-Only per catturare le violazioni innescate da visitatori reali e tag di terze parti.
3. Classifica ogni risultato. Marchialo come attivo o passivo, di prima parte o di terze parti, statico o iniettato da JavaScript, e identifica il template, il campo del database, il plugin, il tag o il fornitore che possiede la fonte.
4. Correggi il riferimento alla fonte. Punta a una risorsa HTTPS funzionante o a un URL relativo sicuro. Non dare per scontato che cambiare http:// in https:// sia sufficiente; verifica che la destinazione supporti effettivamente TLS.
5. Usa CSP come rete di sicurezza. Aggiungi upgrade-insecure-requests solo dopo aver esaminato i risultati. Può ridurre l’esposizione, ma non ripara il record CMS né sostituisce HSTS.
6. Ricrawla e renderizza. Gli errori di contenuto misto attivo dovrebbero essere zero sui template testati; anche le risorse passive dovrebbero risolversi su HTTPS senza fallback.
7. Previeni la ricorrenza. Correggi il template o il flusso di lavoro dell’editor di origine, mantieni la raccolta in modalità di sola segnalazione dove appropriato e assegna le nuove violazioni al proprietario del sistema.

Sintomo → causa probabile → correzione

Test di rilascio per contenuti misti

Test 1: scansione del modello renderizzato

• Scopo: Individuare risorse attive e passive che l’HTML grezzo da solo non rileva.
• Metodo: Esegui il rendering di un URL rappresentativo per ogni modello e stato di interazione; controlla l’output di Console e Network per richieste non sicure o bloccate.
• Risultato atteso: Nessuna sotto-risorsa viene richiesta su HTTP e nessun contenuto attivo viene bloccato.
• Trigger di errore: Qualsiasi avviso di contenuto misto, errore di aggiornamento automatico o mancanza di layout/funzione causata da una risorsa bloccata.
• Azione successiva: Traccia la richiesta fino al suo modello, tag, plugin o campo memorizzato; correggi la fonte e riesegui la scansione.

Test 2: confronto tra sorgente e CSP

• Scopo: Rilevare violazioni introdotte solo per i visitatori reali o da terze parti.
• Metodo: Confronta i risultati del crawler con gli eventi Content-Security-Policy-Report-Only, raggruppati per URL bloccato, modello di pagina, direttiva e proprietario.
• Risultato atteso: Nessuna violazione inspiegabile solo in produzione rimane; il rumore noto è documentato ed escluso in modo mirato.
• Trigger di errore: Una violazione ripetibile assente dal crawl o una fonte di terze parti senza proprietario.
• Azione successiva: Riproduci lo stato del visitatore e correggi o rimuovi l’integrazione che inietta la richiesta.

Test 3: test di ricorrenza dopo la pubblicazione

• Scopo: Verificare che il CMS non generi più nuovi riferimenti non sicuri.
• Metodo: Pubblica un elemento di test tramite il normale flusso editoriale, poi esegui il crawl e il rendering con gli stessi controlli usati per la produzione.
• Risultato atteso: Il markup generato e le risorse caricate utilizzano URL HTTPS validi.
• Trigger di errore: La nuova pagina ricrea un riferimento HTTP precedentemente ripulito dai contenuti più vecchi.
• Azione successiva: Correggi il default dell’editor, il modello, il plugin o la trasformazione dei contenuti prima che il rilascio proceda.

Risorse che meritano il tuo tempo

I miei interventi

• Meglio prevenire che curare con HTTPS — SMX East 2016 (SlideShare) — il mio approfondimento su TLS, gli errori comuni di implementazione HTTPS e le insidie della migrazione che producono contenuti misti in primo luogo. (Disclaimer permanente: è la mia comprensione di questi sistemi, e le statistiche di adozione in esso risalgono al 2016.)

I miei articoli correlati

• Guida introduttiva alla SEO tecnica — dove HTTPS e contenuti misti si inseriscono nel quadro tecnico più ampio.

Dal settore

• Che cos’è il contenuto misto? (web.dev / Google) — la definizione canonica e la distinzione tra attivo e passivo.
• Correggere il contenuto misto (web.dev / Google) — la procedura dettagliata: trovarlo, correggere gli URL delle sotto-risorse, upgrade-insecure-requests e il reporting CSP.
• MDN — upgrade-insecure-requests — esattamente cosa aggiorna, cosa non aggiorna e perché non sostituisce HSTS.
• MDN — block-all-mixed-content — la direttiva di blocco deprecata, per quando la erediti.
• MDN — Contenuto misto — il riferimento sul comportamento del browser per le risorse bloccabili e aggiornabili.
• Abilita HTTPS sui tuoi server (web.dev / Google) — URL relativi e relativi al protocollo e le linee guida circostanti per la configurazione HTTPS.

Statistiche da citare

• Il contenuto misto attivo è bloccato per impostazione predefinita. Google: “Most browsers already block this type of content by default to protect users.” (traduzione) «La maggior parte dei browser blocca già questo tipo di contenuto per impostazione predefinita per proteggere gli utenti.» — il motivo per cui il contenuto misto attivo è un’interruzione funzionale, non un avviso. Fonte
• Il contenuto misto attivo è la minaccia maggiore. La stessa classificazione di Google dei due livelli: “Active mixed content poses a greater threat than passive mixed content.” (traduzione) «Il contenuto misto attivo rappresenta una minaccia maggiore rispetto al contenuto misto passivo.» — dimensiona correttamente il tuo ordine di triage. Fonte
• Il contenuto misto passivo non è più “consentito” in modo sicuro. Google: “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (traduzione) «Fino a poco tempo fa, il contenuto misto passivo veniva caricato in tutti i browser … Questo sta iniziando a cambiare.» — l’assunto “le immagini sono innocue” sta scadendo. Fonte
• upgrade-insecure-requests non è un sostituto di HSTS. MDN lo afferma chiaramente: “does not replace the Strict-Transport-Security (HSTS) header.” (traduzione) «non sostituisce l’header Strict-Transport-Security (HSTS).» — i due controlli risolvono metà diverse del problema. Fonte
• ~89 % del web è su HTTPS (W3Techs, 2026; conferma la cifra attuale), il che è esattamente il motivo per cui le sotto-risorse http:// rimaste su una pagina altrimenti sicura sono la modalità di errore comune ora — le pagine sono HTTPS; il carico è in ritardo. Contesto tramite l’hub HTTPS.

Mettiti alla prova: Contenuto misto

Cinque domande rapide sul contenuto misto. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche