Mixed content warning: come risolvere

Cos'è il Mixed Content

Il Mixed Content si verifica quando una pagina caricata via HTTPS include risorse (immagini, script, CSS, iframe, font) servite via HTTP. Il browser, riconoscendo la combinazione insicura, mostra il classico avviso nella barra degli indirizzi (lucchetto giallo, lucchetto barrato, o nessun lucchetto) e nei casi più gravi blocca proprio il caricamento delle risorse.

Tipi di mixed content

• Passive (Display) Mixed Content: immagini, video e audio HTTP dentro pagine HTTPS. Vengono caricate ma generano un warning visibile
• Active (Script) Mixed Content: script, CSS, iframe, XHR, fetch via HTTP. I browser moderni li BLOCCANO automaticamente perché un'attaccante potrebbe modificarli

Dal 2020 in poi Chrome e Firefox hanno iniziato a bloccare anche il mixed content passivo, downgradando il lucchetto e in alcune versioni rifiutando completamente il caricamento.

Identificare le risorse miste

I metodi più efficaci per scovare mixed content:

1. DevTools del browser: tab Console mostra messaggi tipo Mixed Content: The page at... was loaded over HTTPS, but requested an insecure...
2. Tab Network: filtro per http:// nelle richieste
3. Strumenti online: whynopadlock.com, jitbit.com/sslcheck, missingpadlock.com
4. Crawler automatico: tool come SSL Check o screamingfrog che scansionano l'intero sito
5. Content-Security-Policy report-only: configurare CSP con report e ricevere notifiche su violazioni mixed

Sorgenti tipiche del problema

• URL assoluti hardcoded con http:// nei template
• Riferimenti a CDN, font esterni o iframe di servizi terzi non aggiornati
• Editor WYSIWYG che inseriscono media via percorsi vecchi
• Plugin o temi WordPress non aggiornati per HTTPS
• Configurazioni proxy che riscrivono URL in HTTP
• Database popolato prima della migrazione, con URL legacy

Soluzione 1: Riscrittura del database

Per WordPress il modo più rapido è il Better Search Replace o il classico wp search-replace 'http://tuosito.it' 'https://tuosito.it' --all-tables. Per altre CMS l'approccio è simile: query SQL o script di migrazione che sostituiscano gli URL.

Soluzione 2: Protocol-relative URL

In passato era best practice usare URL del tipo //esempio.com/immagine.png, lasciando al browser la scelta del protocollo. Oggi è SCONSIGLIATO: meglio URL HTTPS espliciti che dichiarano l'intento. Usa // solo nei rari casi in cui devi mantenere compatibilità con vecchi sistemi che potrebbero funzionare anche in HTTP.

Soluzione 3: upgrade-insecure-requests

Direttiva CSP che istruisce il browser a riscrivere automaticamente tutte le richieste HTTP della pagina in HTTPS:

Content-Security-Policy: upgrade-insecure-requests

È una pezza utile durante la migrazione, ma non risolve risorse che non hanno HTTPS attivo. Va combinata con la pulizia del database.

Soluzione 4: Block-all-mixed-content

Versione più restrittiva: il browser blocca tutto il mixed content, anche quello passivo. Utile come check finale dopo la pulizia:

Content-Security-Policy: block-all-mixed-content

Best practice post-fix

• Esegui un crawl completo dopo ogni modifica importante
• Configura CSP con reporting per ricevere alert su nuove violazioni
• Mantieni un test automatico che verifica l'assenza di stringhe http:// nelle pagine principali
• Aggiorna documentazione e template del team per evitare regressioni
• Verifica che le newsletter inviate non includano risorse HTTP

Hai bisogno di aiuto?

Se vuoi gestione SSL dal team di G Tech Group, scrivici tramite il modulo di contatto.