Come rilevare e correggere gli elementi non sicuri SSL

In breve: Elementi non sicuri SSL: Se il certificato SSL è valido ma il browser segnala elementi non sicuri, la causa più comune è il mixed content: la pagina principale viene aperta in HTTPS, mentre una o più risorse sono ancora richieste tramite HTTP.

Elementi non sicuri SSL: obiettivo e requisiti

Se il certificato SSL è valido ma il browser segnala elementi non sicuri, la causa più comune è il mixed content: la pagina principale viene aperta in HTTPS, mentre una o più risorse sono ancora richieste tramite HTTP. Per risolvere, individua nella console del browser l’URL esatto, verifica che la risorsa funzioni davvero in HTTPS, correggi il riferimento nel punto che lo genera, svuota tutte le cache e ripeti il controllo.

apri la pagina interessata in una finestra privata, premi F12 , seleziona Console e ricarica. Cerca messaggi contenenti Mixed Content oppure richieste che iniziano con http:// . Non limitarti a cambiare la lettera nel codice: prova prima l’indirizzo HTTPS della risorsa. Se risponde correttamente, aggiorna l’URL nel CMS, nel tema, nel plugin, nel CSS, nel database o nella configurazione CDN che lo produce.

Importante: installare o rinnovare il certificato non converte automaticamente tutti i collegamenti memorizzati nel sito. Certificato, redirect a HTTPS e contenuti della pagina sono livelli distinti. Prima di modificare database o file crea un backup e, su un sito importante, prova l’intervento in staging.

Che cosa sono gli elementi non sicuri SSL

Una pagina contiene risorse miste quando il documento è caricato tramite una connessione HTTPS, ma richiama una risorsa tramite un protocollo non sicuro, normalmente HTTP. Può trattarsi di immagini, fogli di stile, script JavaScript, font, video, audio, iframe, chiamate fetch o richieste effettuate in modo dinamico.

La documentazione MDN sul mixed content spiega che queste richieste indeboliscono la protezione offerta da HTTPS: una risorsa trasmessa senza cifratura può essere osservata o alterata durante il percorso. Uno script modificato, per esempio, potrebbe cambiare qualsiasi parte della pagina.

Un esempio essenziale è questo:

• pagina: https://esempio.it/contatti/;
• immagine richiesta: http://esempio.it/wp-content/uploads/foto.jpg;
• risultato: la pagina HTTPS contiene una richiesta HTTP e quindi presenta mixed content.

Il fatto che la risorsa appartenga allo stesso dominio non la rende sicura: è il protocollo della singola richiesta a contare. Anche una risorsa esterna può essere usata, ma deve essere disponibile attraverso HTTPS con un certificato valido.

Certificato non valido e mixed content non sono lo stesso problema

Prima di intervenire devi capire quale livello non funziona. I due problemi possono produrre avvisi simili per un utente, ma richiedono soluzioni diverse.

Se non hai ancora verificato il primo livello, consulta la guida Xlogic su come controllare se il certificato SSL è installato ed è valido. La presenza di un certificato corretto è un prerequisito, non la prova che ogni risorsa della pagina utilizzi HTTPS.

Come si comportano i browser moderni

Le vecchie guide distinguevano spesso tra contenuto misto “attivo” e “passivo”. Oggi è più utile ragionare tra richieste che il browser può tentare di aggiornare automaticamente e richieste che deve bloccare. Immagini, audio e video possono in alcuni casi essere convertiti automaticamente da HTTP a HTTPS; script, fogli di stile, iframe e varie richieste applicative vengono normalmente bloccati perché potrebbero compromettere l’intera pagina.

Non devi però considerare l’aggiornamento automatico una soluzione. Se il browser prova HTTPS ma il server esterno non lo supporta, la risorsa non viene caricata. Inoltre il comportamento può cambiare in base al tipo di contenuto, all’indirizzo usato e alla versione del browser. Un sito corretto deve generare direttamente URL sicuri.

Anche la grafica degli indicatori è cambiata nel tempo. Non affidarti al vecchio “lucchetto verde” o al colore di un’icona: apri le informazioni del sito e soprattutto la console degli strumenti per sviluppatori. Un normale collegamento che porta l’utente a un’altra pagina HTTP non è una sottorisorsa mista della pagina corrente, ma conduce comunque a una destinazione non protetta e va valutato separatamente.

Come trovare la risorsa HTTP con gli strumenti del browser

Gli strumenti per sviluppatori sono il controllo principale perché mostrano ciò che il browser ha richiesto davvero, comprese risorse inserite dopo il caricamento da JavaScript o CSS.

1. apri l’URL esatto che presenta il problema in una finestra privata;
2. premi F12 oppure usa il menu del browser per aprire gli strumenti per sviluppatori;
3. seleziona la scheda Console;
4. attiva, se disponibile, l’opzione che conserva i log;
5. ricarica la pagina con la cache disattivata;
6. cerca Mixed Content, blocked oppure http://;
7. copia l’URL completo indicato nel messaggio e annota il tipo di risorsa.

Passa poi alla scheda Network, ricarica ancora e filtra per protocollo, stato o nome del file. Controlla la colonna che indica chi ha avviato la richiesta: può aiutarti a capire se l’URL proviene dall’HTML, da un foglio CSS, da uno script, da un plugin o da una risorsa incorporata.

La scheda Security, quando presente, riassume il contesto sicuro e permette di distinguere il certificato della pagina dai problemi delle sottorisorse. Ripeti il test sia nella homepage sia nell’URL specifico: il mixed content può essere limitato a un solo articolo, a un template, a un modulo o a una pagina caricata dopo il consenso cookie.

Controllare il codice sorgente e il CSS

Visualizza il codice sorgente della pagina e cerca http://. Questo metodo trova molti riferimenti presenti nell’HTML iniziale, ma non intercetta sempre le richieste costruite da JavaScript o caricate da fogli di stile esterni. Per questo non sostituisce Console e Network.

Se l’errore riguarda uno sfondo, un font o un’icona, apri il foglio CSS segnalato e cerca direttive come url(http://...) oppure @import. Nei page builder e nei sistemi di cache il CSS può essere generato in un file separato: dopo avere corretto il dato sorgente dovrai rigenerare i file CSS e pulire la cache, non modificare soltanto il file generato che verrà sovrascritto.

Controllare il sito con WhyNoPadlock

Un controllo esterno come WhyNoPadlock può offrire una seconda lettura della pagina pubblica e un elenco di riferimenti non sicuri. Inserisci soltanto URL pubblici: non usare pagine di staging protette, indirizzi amministrativi, URL con token o contenuti che richiedono autenticazione.

Le immagini seguenti appartengono alla versione originale del 2017. Restano utili come esempio del risultato “elementi sicuri/non sicuri”, ma interfaccia, categorie e indicatori del servizio possono essere cambiati. Usa sempre il nome e l’URL della risorsa rilevata, non la posizione del messaggio nello screenshot.

Un servizio esterno vede soltanto ciò che può caricare come visitatore anonimo. Può non eseguire tutte le interazioni, non accettare il consenso cookie, non raggiungere pagine riservate oppure ricevere una variante di cache differente. Se il controllo esterno non trova nulla ma il browser mostra l’errore, considera autorevole la richiesta effettivamente registrata in Console o Network.

Cause comuni degli elementi non sicuri in WordPress

Su WordPress gli URL HTTP possono trovarsi in molti punti. Individuare il file segnalato non basta: devi risalire al dato o alla configurazione che genera il riferimento.

• Indirizzo WordPress e indirizzo sito: le opzioni siteurl e home possono contenere ancora HTTP.
• Contenuti e metadati: pagine, articoli, widget, menu, campi personalizzati e impostazioni dei page builder possono conservare URL assoluti.
• Tema o child theme: un URL può essere scritto direttamente in un template, in un foglio di stile o in una configurazione.
• Plugin: moduli, slider, sistemi pubblicitari, mappe, font o script di terze parti possono richiamare una risorsa non sicura.
• CSS generato: builder e plugin di ottimizzazione possono conservare vecchi URL in file compilati.
• Cache: cache pagina, oggetti, browser, LiteSpeed o CDN possono continuare a servire una versione precedente.
• CDN o dominio statico: l’URL configurato può usare HTTP oppure il certificato del dominio CDN può non essere valido.
• Proxy inverso: WordPress può non riconoscere la richiesta originale come HTTPS se proxy e intestazioni non sono configurati in modo coerente.
• Risorsa esterna: il fornitore può non offrire HTTPS; in questo caso non puoi correggere la risorsa cambiando soltanto il protocollo.

La documentazione WordPress ricorda di controllare WP_HOME, WP_SITEURL, le opzioni home e siteurl e gli URL HTTP rimasti nel database dopo il passaggio a SSL. Consulta la sezione ufficiale sugli errori di accesso e configurazione HTTPS di WordPress.

Come correggere gli URL HTTP in WordPress

1. Verificare gli indirizzi generali

In Impostazioni → Generali controlla che Indirizzo WordPress (URL) e Indirizzo sito (URL) usino il dominio corretto in HTTPS. Se i campi sono bloccati, i valori potrebbero essere definiti in wp-config.php tramite WP_HOME e WP_SITEURL. Non aggiungere definizioni duplicate: verifica prima la configurazione esistente.

Da WP-CLI puoi leggere i valori senza modificarli:

wp option get home
wp option get siteurl

Se usi un proxy o una CDN, un loop di redirect o la generazione intermittente di HTTP può dipendere dal riconoscimento del protocollo originale. In quel caso va corretta la configurazione tra proxy e server; forzare valori nel CMS senza capire il flusso può nascondere il problema o creare un loop.

2. Correggere il punto che genera la risorsa

Se Console indica un’immagine inserita in una pagina, modifica la pagina e seleziona nuovamente la risorsa sicura. Se indica un CSS del tema, correggi il tema o il child theme. Se il riferimento proviene da un plugin, controlla l’impostazione corrispondente e aggiorna il componente; evitare modifiche dirette ai file del plugin, perché un aggiornamento le cancellerebbe.

Per una risorsa esterna esegui prima una prova aprendo la versione HTTPS in una nuova scheda. Deve rispondere senza avvisi, redirect verso HTTP o errori del certificato. Se il fornitore non supporta HTTPS, rimuovi la risorsa, sostituiscila con un’alternativa sicura o, quando licenza e condizioni lo consentono, ospitala localmente.

3. Eseguire una sostituzione nel database soltanto con backup

Dopo una migrazione completa da HTTP a HTTPS possono esistere molti URL interni memorizzati nel database. Non eseguire una sostituzione SQL grezza: WordPress e i plugin possono conservare dati serializzati e una modifica non compatibile può danneggiarli. WP-CLI gestisce questi dati in modo più sicuro e permette una simulazione.

Prima crea un backup, sostituisci example.it con il dominio reale e avvia soltanto il controllo:

wp search-replace 'http://example.it' 'https://example.it' \
  --all-tables-with-prefix --precise --recurse-objects --dry-run

Esamina il numero e le tabelle delle sostituzioni. Se il dominio, il prefisso e il perimetro sono corretti, ripeti il comando senza --dry-run. Non sostituire alla cieca ogni stringa http://: potresti modificare collegamenti esterni, esempi di codice, namespace o servizi che non dispongono di HTTPS.

Dopo l’operazione verifica pagine, media, widget, menu, form e area amministrativa. Se usi un page builder, rigenera i suoi CSS o dati compilati con la funzione prevista dal componente.

4. Svuotare cache e CDN

Pulisci la cache WordPress o LiteSpeed, l’eventuale cache del server, la CDN e infine la cache del browser. Esegui il purge dopo avere corretto la sorgente: svuotare la cache prima della modifica produce soltanto una nuova copia dello stesso HTML errato.

Se l’errore compare solo su alcuni dispositivi o nodi geografici, confronta gli header e l’HTML restituiti dalla CDN. Una cache parziale può servire vecchi file CSS o una pagina generata quando gli URL erano ancora HTTP.

Il redirect da HTTP a HTTPS risolve il mixed content?

Un redirect globale è necessario per portare visitatori e motori di ricerca alla versione sicura del sito, ma non sostituisce la correzione degli URL nel contenuto. I browser possono decidere di bloccare una richiesta mista prima di seguirne il redirect, soprattutto per le risorse più pericolose. Inoltre ogni redirect aggiunge una richiesta inutile.

Dopo una migrazione, aggiorna link interni, canonical e sitemap affinché usino direttamente HTTPS. Google considera il passaggio da HTTP a HTTPS una modifica di URL e raccomanda di preparare redirect permanenti e controlli coerenti, come descritto nella guida ufficiale alle migrazioni con cambio URL.

Usare Content Security Policy con prudenza

La direttiva Content-Security-Policy: upgrade-insecure-requests chiede al browser di trattare gli URL HTTP come HTTPS. Può essere una protezione aggiuntiva durante la gestione di un sito storico, ma non rende disponibile una risorsa che non supporta HTTPS e può quindi farla scomparire. La documentazione MDN su upgrade-insecure-requests ne descrive comportamento e limiti.

Non aggiungere una policy copiata da un altro sito senza inventariare script, font, frame, API e CDN necessari. Una CSP più ampia può bloccare funzioni legittime. Configurala a livello di server o applicazione con una procedura verificata e considera il reporting prima di applicare regole restrittive in produzione.

La vecchia direttiva block-all-mixed-content è ormai considerata obsoleta nelle specifiche moderne. Non è quindi una soluzione da aggiungere automaticamente. L’obiettivo resta generare URL HTTPS corretti alla fonte.

Procedura di verifica finale

Dopo le correzioni esegui una verifica completa, non soltanto un controllo visivo della homepage. La guida di web.dev per correggere il mixed content raccomanda di individuare gli URL HTTP, verificare la disponibilità in HTTPS, aggiornare i riferimenti e controllare il risultato.

1. pulisci tutte le cache applicative, server e CDN;
2. apri una finestra privata e cancella i log della console;
3. ricarica la pagina con cache disattivata;
4. verifica che Console non mostri messaggi Mixed Content;
5. in Network controlla che le sottorisorse usino HTTPS e rispondano senza errori;
6. prova homepage, pagine interne, form, menu, slider e contenuti caricati dopo un’interazione;
7. controlla sia desktop sia mobile e, se rilevante, utenti autenticati e anonimi;
8. ripeti un controllo esterno sulla pagina pubblica;
9. verifica che l’URL HTTP della pagina reindirizzi una sola volta alla versione HTTPS corretta;
10. monitora log ed errori dopo la pubblicazione.

Se il certificato manca o deve essere emesso, consulta anche la guida Xlogic su come ottenere un certificato SSL gratuito. Se invece il certificato è valido e il problema resta nel sito, apri un ticket indicando URL pubblico, orario del test e risorsa segnalata dalla console. Non inviare password o dati di accesso nel testo del ticket.

Domande frequenti

Guide Xlogic correlate

• Come ottenere un certificato SSL gratuito
• Procedura installazione certificati SSL a pagamento
• Come posso scoprire se il Certificato SSL è stato installato correttamente ed è valido?

Fonti tecniche

• documentazione MDN sul mixed content
• documentazione MDN su upgrade-insecure-requests