Kevert tartalom

Kevert tartalomról akkor beszélünk, ha az oldal maga https://-en érkezik, de egyes részeit (képet, szkriptet, stíluslapot) titkosítatlan http:// címről tölti be. Az MDN szerint a böngészők a kevert tartalmat két csoportra osztják: a „frissíthető” tartalmat (például képek, videók) automatikusan https-re cserélik, a „blokkolandót” (például szkriptek) pedig letiltják. Ezért hiányozhat egy kép vagy egy szkript, és az oldal egy része nem működik.

A web.dev megkülönbözteti a passzív (kép, videó, hang) és az aktív kevert tartalmat (szkript, stíluslap, iframe). Az aktív tartalomra irányuló támadással a támadó szinte bármit megtehet az oldalon.

Hogyan mérjük

Ez a teszt böngészős: a riport egy valódi, fej nélküli böngészőben (Lighthouse, mobil emulációval) betölti az oldalt, és a Lighthouse is-on-https ellenőrzésének találatait nézi. Ez a Chrome dokumentációja szerint azt jelzi, ha az oldal https-en érkezik, de védtelen (HTTP) erőforrást kér. A riport azokat a találatokat számolja, amelyek http: címűek, legfeljebb 20-ig.

Eredmény	Mikor
Megfelelő	nincs http:// című erőforrás (0 darab)
Hiba	legalább egy erőforrás http:// címről töltődik be (a riport a darabszámot és legfeljebb 10 címet mutatja)
Nem értékelhető	a végső oldal nem https:// (akkor kevert tartalomról nincs értelme beszélni)

Amit a teszt nem csinál:

• Csak a kezdőoldalt tölti be, az aloldalakat nem.
• A darabszám legfeljebb 20: ha a riport 20-at mutat, az „húsz vagy több”.
• Amit az oldal csak interakcióra (kattintás, görgetés, űrlap) tölt be, azt nem biztos, hogy látja.

Hogyan javítsd

A cél az, hogy minden erőforrás https:// címről jöjjön. A riport által kiírt http:// címeket keresd meg a forrásban, és írd át.

1. Nézd meg a riportban a mutatott http:// címeket. Az azonos domain alatti címek általában a saját tartalmadban vannak (régi bejegyzések, a téma, bővítmények), a külső címek harmadik fél beágyazásai.
2. Írd át a címeket https://-re. Külső erőforrásnál ellenőrizd, hogy a szolgáltató elérhetővé teszi-e https-en. Az MDN figyelmeztet: ha a kért erőforrás nem érhető el https-en, a kérés sikertelen lesz, nem esik vissza http-re.
3. Ha sok a hibás cím, használd az alábbi platformonkénti megoldásokat. Az upgrade-insecure-requests és a Cloudflare átírása a hibás címek javítása nélkül is segít, de a forrás javítása a tartós megoldás.

HTML

HTML

<!-- Hibás -->
<img src="http://pelda.hu/kep.webp" alt="Kép">

<!-- Helyes -->
<img src="https://pelda.hu/kep.webp" alt="Kép">

WordPress

A hibás címek jellemzően az adatbázisban vannak (bejegyzések, beállítások). A WP-CLI search-replace parancsa kicseréli őket. A kódrészlet az adatbázist a home-mappádba menti (ne a WordPress mappájába, mert onnan letölthető), utána csak megmutatja, mi változna (--dry-run):

Terminál

(umask 077; wp db export ~/before-update-mixed-content.sql) &&
wp search-replace 'http://pelda.hu' 'https://pelda.hu' --skip-columns=guid --dry-run &&
wp search-replace 'http://www.pelda.hu' 'https://pelda.hu' --skip-columns=guid --dry-run

Cseréld a pelda.hu helyére a saját domainedet (és a fő címnek megfelelően a www-t). A --skip-columns=guid a guid oszlopot hagyja ki; a WP-CLI dokumentációja is ezt mutatja a kapcsoló példájaként. Ha a lista rendben van, futtasd le ugyanezeket a parancsokat --dry-run nélkül:

Terminál

wp search-replace 'http://pelda.hu' 'https://pelda.hu' --skip-columns=guid
wp search-replace 'http://www.pelda.hu' 'https://pelda.hu' --skip-columns=guid

A mentést ellenőrzés után töröld. Ellenőrizd a WordPress beállításaiban is (Beállítások, Általános), hogy a WordPress- és a webhelycím https://-sel kezdődik. A téma és a bővítmények fájljaiban beégetett http:// címeket a fájlokban kell javítani (Bedrocknál is ugyanez a parancs fut, a WordPress mappájából).

nginx

A böngészőt az upgrade-insecure-requests CSP-direktíva utasítja, hogy az oldal minden http:// címét https://-ként kezelje. Az MDN szerint ennek a kérések a hálózatra sem jutnak ki titkosítatlanul. A server blokkba:

nginx

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Ha a Content-Security-Policy kártyáját is megcsinálod, ezt utána add hozzá: az MDN szerint a CSP-mechanizmus több szabályt is megenged egy erőforráshoz, és a böngésző mindegyiket betartja. Ha egy location blokkban is van add_header, oda is kell, mert az nginx csak akkor örököl, ha az adott szinten nincs add_header.

Apache (.htaccess)

.htaccess

<IfModule mod_headers.c>
    Header always append Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

Cloudflare

Cloudflare: SSL/TLS, Edge Certificates, Automatic HTTPS Rewrites: On. A Cloudflare dokumentációja szerint ez az oldalad azon erőforrásait és hivatkozásait írja át http-ről https-re, amelyek https-en is kiszolgálhatók.

Ha a CSP-direktívát is a Cloudflare-rel adnád hozzá, használd az Add static műveletet (nem a Set static-ot), különben felülírnád a meglévő azonos nevű fejlécet. Cloudflare: Rules, Overview, Create rule, Response Header Transform Rule:

Cloudflare

Add static: Content-Security-Policy = upgrade-insecure-requests

Hogyan ellenőrizd

Futtasd újra a riportot. Gyors első ellenőrzés a kiszolgált HTML-ben (ez csak a HTML forrásában lévő címeket találja meg, a szkript vagy a stíluslap által később betöltöttet nem):

Terminál

curl -s "https://pelda.hu/?v=1" | grep -oE 'http://[^"'"'"' )]+' | sort -u

Ha a parancs nem ír ki semmit, a HTML-ben nincs http:// cím.