Il lucchetto sulla home non basta. Mixed content è una pagina HTTPS che pesca HTTP. Immagini auto-promosse, script bloccati. Il plugin «forza HTTPS» non riscrive il HTML.
Un lucchetto in barra non basta. Se la pagina è in HTTPS e carica uno script, un font o un iframe in HTTP, quella risorsa è mixed content. Il browser, oggi, la blocca o la riscrive. Un plugin «forza HTTPS» sulla home non riscrive gli URL HTTP lasciati nel HTML di dieci anni fa.
In breve: mixed content è una pagina sicura che pesca risorse insicure. Immagini, audio e video vengono auto-promossi a HTTPS. Script, CSS, font, XHR, iframe restano blockable: il browser li ferma. upgrade-insecure-requests non sostituisce HSTS. Verifica del 18 settembre 2026 su MDN e sulla specifica W3C Mixed Content.
Cosa trovi in questo articolo
Cosa è mixed content (e cosa non è il lucchetto)
MDN, nella guida Mixed content, lo definisce così: una pagina caricata da un’origine sicura (HTTPS) che richiede risorse su un canale non sicuro (HTTP). Lo script in chiaro può essere letto o modificato da chi sta sul percorso. Un’immagine in chiaro può essere sostituita. Il lucchetto sulla navigazione top-level non copre quei fetch.
La specifica W3C Mixed Content (Editor’s Draft, 23 febbraio 2023) tratta anche i mixed downloads: un download avviato da un contesto sicuro ma pescato in HTTP. Il file esce dalla sandbox del browser. MDN: i browser dovrebbero bloccarli di default.
Questo pezzo sta nel cluster Sicurezza, accanto al certificato TLS, a HSTS e alla CSP. TLS cifra il transito della pagina. HSTS dice al browser di non uscire più in HTTP su quel nome. Mixed content è il sotto-problema: la pagina è già in HTTPS, le dipendenze no. I flag del cookie sono un quarto strato, sull’header di sessione. Quattro mestieri. Il plugin che promette tutti e quattro è un quinto script.
Due categorie: upgradable e blockable
Le versioni recenti della specifica non parlano più di «optionally blockable» contro «blockable». MDN allinea i browser moderni a due cestini: ciò che viene auto-promosso da HTTP a HTTPS, e ciò che viene bloccato. Se l’upgrade fallisce (la risorsa non esiste in HTTPS, o l’host è un indirizzo IP), la richiesta non passa in chiaro: fallisce.
| Categoria | Esempi | Cosa fa il browser |
|---|---|---|
| Upgradable | immagini (src), background-image, audio, video e source associati | riscrive lo schema da http a https e ritenta |
| Blockable | tutto il resto: script esterni, fogli di stile, font, XHR/fetch, iframe, worker | blocca. La pagina resta, la dipendenza no |
MDN precisa i limiti dell’upgrade sulle immagini: vale per l’attributo src, non per tutti i casi di srcset o picture. Un host scritto come indirizzo IP non entra nell’auto-upgrade. Lo script di un vecchio CDN ancora in HTTP, o il webfont del tema, o l’iframe del form «prenota», oggi non «si vedono lo stesso»: spariscono. In console resta un mixed content warning. In pagina resta un buco.
Il vecchio distinguo «active» (script, fogli di stile) contro «passive» (immagini) descriveva un web in cui le immagini HTTP su pagine HTTPS venivano mostrate, col lucchetto degradato. Quel mondo, scrive MDN, è superato: le immagini si upgradano; il resto si blocca. block-all-mixed-content in CSP è marcato obsoleto proprio per questo: ciò che non è già bloccato viene upgradato, la direttiva non serve più nei progetti nuovi.
upgrade-insecure-requests non è HSTS
La direttiva CSP upgrade-insecure-requests dice al browser di trattare gli URL HTTP del sito come se fossero HTTPS. Serve alle code di URL legacy. MDN lo scrive senza ambiguità: non sostituisce HSTS. Non copre chi arriva da un link HTTP su un sito terzo. Non chiude lo SSL stripping sulla prima richiesta. HSTS, con una rampa di max-age, resta l’header sul nome. La direttiva CSP resta un nastro adesivo sulle dipendenze interne, mentre si riscrivono.
MDN avverte anche l’ordine: upgrade-insecure-requests viene valutata prima di block-all-mixed-content. Se c’è la prima, la seconda non fa nulla. Si sceglie. Non si incollano entrambe «per sicurezza», salvo il caso stretto di browser vecchi che non forzano l’HTTPS dopo un redirect. Nei progetti nuovi, HSTS + URL già in HTTPS + una CSP che non sia piena di unsafe-inline. Il dettaglio della policy sta nel pezzo sulla CSP.
Un plugin «forza HTTPS» che emette un 301 sulla home è il gradino sulla porta 80. Non riscrive gli URL HTTP assoluti lasciati nel corpo, nei webfont, nell’iframe del prenota. Mixed content si sistema nel HTML, nel CSS, nel CDN e nell’origin, non nel popup del plugin.
Come si trova e come si sistema
MDN indica la console del browser: i mixed content warning nominano URL e tipo. Si apre la pagina in HTTPS, si guarda Network, si filtrano gli scheme http. Si cerca nel tema, nei widget, nei vecchi articoli, nei feed. Tre interventi, in quest’ordine:
| Intervento | Cosa fa | Cosa non fa |
|---|---|---|
| Servire la risorsa in HTTPS | stesso host, certificato valido, stesso path | non inventa un file che sul CDN in HTTPS non c’è più |
| Riscrivere gli URL in pagina | https:// o URL relativi protocol-relative solo se l’origin è già sicura; meglio URL assoluti HTTPS o path relativi | non copre i contenuti già in cache, i feed, le email HTML |
Content-Security-Policy: upgrade-insecure-requests | il browser ritenta in HTTPS le dipendenze HTTP | non è HSTS; se la risorsa in HTTPS non esiste, resta un 404 |
URL relativi (/media/foto.jpg) ereditano lo schema della pagina: su HTTPS restano HTTPS. Sono la forma più noiosa e la più solida. Gli URL HTTP assoluti nel corpo degli articoli, nelle copertine vecchie, nei banner, sono il debito. Un search-and-replace sul database senza inventario è un modo per rompere i link che puntano, di proposito, a un archivio solo HTTP. Si fa un elenco, si verifica che l’HTTPS risponda, poi si riscrive.
La guida TLS di MDN, Transport Layer Security (TLS) configuration, chiede che tutte le risorse, qualunque origine, viaggino su canale sicuro. Mixed content è il nome di quando quella frase non è vera. Il certificato della home, da solo, non la rende vera.
Errori da evitare
Credere che «il sito è in HTTPS» perché la home redirige: il corpo degli articoli può ancora citare URL HTTP assoluti.
Installare un plugin «forza HTTPS» e dare per sistemati script e webfont.
Mettere
upgrade-insecure-requestse spegnere HSTS, o il contrario, come se fossero la stessa leva.Lasciare
block-all-mixed-contentin una policy nuova: è obsoleto.Hostare lo script del checkout su HTTP e sorprendersi che il browser lo blocchi, mentre le immagini «si vedono» perché sono state upgradate.
Usare un IP in
src: l’auto-upgrade, scrive MDN, non ci passa.Confondere mixed content con un certificato scaduto: due diagnostiche, due interventi. Il certificato sta nella checklist TLS.
In sintesi
Mixed content è una pagina HTTPS con dipendenze HTTP. Il browser upgrada immagini, audio e video; blocca script, CSS, font, fetch, iframe. Si riscrivono gli URL, si serve tutto in HTTPS, si usa upgrade-insecure-requests come nastro, non come sostituto di HSTS. Il plugin sulla porta 80 non legge il HTML. HSTS, TLS, CSP e questo elenco restano quattro strati.
Fonti
MDN, Mixed content (consultata il 18 settembre 2026): definizione, upgradable contro blockable, auto-upgrade, mixed downloads, console.
W3C WebAppSec, Mixed Content, Editor’s Draft 23 febbraio 2023: mixed content, autoupgrade, mixed downloads.
MDN,
upgrade-insecure-requestseblock-all-mixed-content(obsoleta): ordine di valutazione, non sostituisce HSTS.MDN, TLS configuration: tutte le risorse su canale sicuro.
Immagine di copertina: tastiera e schermo. Il mixed content si vede in console, sulle richieste HTTP di una pagina HTTPS, non nel lucchetto della home. Foto di Thomas Lefebvre, Unsplash via Wikimedia Commons, licenza CC0.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
