Errore 'Mixed content' SSL: come risolvere
Il warning 'Mixed content' compare quando una pagina servita in HTTPS carica risorse in HTTP (immagini, CSS, JS, iframe). I browser moderni bloccano gli script e segnalano i media: l’icona del lucchetto sparisce o diventa rossa. Con WP Error Monitor puoi tracciare tutti gli URL coinvolti e rimediare in modo strutturato.
Tipi di mixed content
Esistono due categorie: 'activè (script, iframe, XHR, fetch, link CSS) che viene bloccato dai browser moderni, e 'passivè (img, audio, video) che viene caricato ma triggera warning. Active mixed content è pericoloso perchè permette MITM attack che modificano lo script. Passive è meno critico ma fa perdere il lucchetto verde.
Come WP Error Monitor traccia il problema
L’agent include un snippet JS opzionale che intercetta gli errori 'Mixed Content' del browser e li invia al CRM. Riceverai eventi con: URL della pagina, URL della risorsa HTTP, tipo (active/passive), e in molti casi la riga del DOM che ha generato il caricamento. Questo permette di identificare se il problema viene da contenuto editor, tema o plugin.
Strategie di fix
1) wp_options siteurl/home in HTTPS; 2) plugin 'Really Simple SSL’ per rewrite automatico; 3) script WP-CLI per search-replace del DB: wp search-replace 'http://sito.it' 'https://sito.it' --all-tables --skip-columns=guid; 4) hardcoded HTTP in tema/plugin (cerca e sostituisci nel codice); 5) Content-Security-Policy con upgrade-insecure-requests come fallback ai casi remoti irrisolvibili.
HSTS e impatti
HSTS (Strict-Transport-Security) è un'header che dice al browser 'tratta sempre questo sito come HTTPS, anche se l’utente digita http://'. Valore tipico: max-age=31536000 (1 anno), includeSubDomains, preload. Pro: blocca downgrade attack. Contro: una volta attivo per max-age, il browser non si rivolge più su HTTP, quindi se rinunci a HTTPS i visitatori non riescono ad accedere. Attiva HSTS solo dopo aver verificato che HTTPS funzioni stabilmente per settimane.
Preload list HSTS
Sottomettere il dominio alla 'HSTS preload list' (hstspreload.org) fa sì che browser come Chrome/Firefox lo trattano come HTTPS-only anche al primo accesso. Requisiti: HSTS attivo con max-age >= 1 anno, includeSubDomains, preload directive, certificate valido. Rimozione dalla list è difficile (mesi), quindi sottomettere solo siti con strategia HTTPS-only consolidata.
CSP upgrade-insecure-requests
La direttiva CSP 'upgrade-insecure-requests' istruisce il browser a riscrivere automaticamente http:// in https:// per le risorse, evitando manual fix di tutti i link. Setup nginx: 'Content-Security-Policy: upgrade-insecure-requests;'. Effetto: img src http://cdn.tld/foo.jpg viene caricato come https://cdn.tld/foo.jpg, se cdn supporta HTTPS funziona, altrimenti fallisce graceful. Caveat: NON sostituisce il fix del DB (gli URL stay in HTTP nei post_content), ma evita la rottura UX mentre fai cleanup. Combina con cspr (CSP report-uri) per identificare risorse che ancora servono HTTP-only e vanno migrate.
Plugin SSL e auto-fix vs manual
Plugin tipo 'Really Simple SSL’ fa search-replace automatico per fixare URL. Pro: setup in 5 minuti, copre il 95% dei casi. Contro: il plugin resta sempre attivo (rimuovendolo, URL tornano HTTP), aggiunge overhead per ogni richiesta, fix non è visibile nel DB ma calcolato a runtime. Approccio manuale (search-replace WP-CLI poi disinstalla plugin) è superiore per progetti seri: fix permanente nel DB, no overhead runtime, pulizia codebase. Compromesso: usa il plugin per emergenza/rapido fix, poi pianifica search-replace permanente e rimuovi.
Verifica completa post-fix
Dopo aver applicato fix per mixed content, esegui verifica completa: 1) SSL Labs (ssllabs.com) deve dare grade A o A+, 2) WhyNoPadlock (whynopadlock.com) deve mostrare zero issue, 3) Lighthouse audit Best Practices score 100, 4) Browser DevTools Console deve essere pulita su tutte le pagine principali (home, prodotti, checkout, blog), 5) Search Console di Google non deve mostrare 'Mixed Content' nella sezione Security. Solo quando tutti i cinque check sono verdi puoi considerare il fix completo e attivare HSTS in confidence.
Procedura passo-passo
- Apri WP Error Monitor e filtra 'category = mixed_content'.
- Esamina la top 10 URL HTTP che vengono caricati.
- Per ogni URL identifica fonte: editor (post/page), tema, plugin, CDN.
- Lancia WP-CLI search-replace per i contenuti del DB.
- Modifica wp_options siteurl e home in https://.
- Per i tema custom usa get_template_directory_uri() invece di hardcoded URL.
- Aggiungi header Content-Security-Policy: upgrade-insecure-requests come safety net.
- Verifica con browser DevTools che la console sia pulita.
- Verifica che HTTPS funzioni stabilmente per 30+ giorni prima di HSTS.
- Attiva HSTS con max-age basso (es. 1 settimana) inizialmente, poi alza.
Errori comuni e come risolverli
- Search-replace rompe URL guid: Usa sempre --skip-columns=guid: la colonna guid non va modificata mai.
- Plugin di terze parti che genera HTTP: Contatta autore plugin o sovrascrivi tramite filter wp_get_attachment_url.
- CDN che restituisce HTTP: Configura CDN per servire solo HTTPS e abilita HSTS sul certificato.
- Utenti loccati fuori dopo HSTS: max-age troppo lungo + downgrade temporaneo a HTTP: pianifica HSTS solo a HTTPS stabile.
- Sottodomini non coperti: Aggiungi includeSubDomains, ma verifica TUTTI i sottodomini siano HTTPS prima.
Domande frequenti
D: Posso ignorare il mixed content passive?
R: No, anche se non bloccato fa perdere fiducia agli utenti (lucchetto rotto).
D: HSTS risolve mixed content?
R: Solo per le richieste dello stesso dominio: per dominii esterni serve upgrade-insecure-requests in CSP.
D: Lo snippet JS impatta performance?
R: <1KB minificato, async, impatto trascurabile.
D: HSTS impatta SEO?
R: Marginalmente positivo: Google preferisce siti HTTPS.
D: Posso testare HSTS senza preload?
R: Sì, il preload è opzionale: HSTS funziona anche solo con header.
Hai bisogno di aiuto?
Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.