Wat is mixed content?

Mixed content treedt op wanneer een webpagina die via een veilige HTTPS-verbinding wordt geladen, bronnen bevat (afbeeldingen, scripts, stylesheets, fonts, iframes) die via een onveilige HTTP-verbinding worden geladen. Dit is een beveiligingsprobleem omdat de HTTP-bronnen kunnen worden onderschept, gewijzigd of vervangen door een aanvaller, ook al is de hoofdpagina zelf versleuteld. Het hangslotpictogram in de browser verdwijnt en bezoekers zien waarschuwingen die hun vertrouwen in uw site ondermijnen.

Passieve versus actieve mixed content

Browsers maken onderscheid tussen twee categorieën mixed content en behandelen elk anders:

• Passieve (weergave) mixed content: dit omvat afbeeldingen, audio en video die via HTTP worden geladen. Het risico is lager omdat deze bronnen het gedrag van de pagina niet rechtstreeks kunnen wijzigen. Een aanvaller zou een afbeelding kunnen verwisselen (bijvoorbeeld ongepaste inhoud tonen), maar geen code kunnen injecteren. Oudere browsers laadden passieve mixed content met een waarschuwing. Moderne browsers blokkeren deze ook steeds vaker, hoewel sommige het nog toestaan met een verminderde beveiligingsindicator.
• Actieve mixed content: dit omvat scripts, stylesheets, iframes, fonts en XMLHttpRequests die via HTTP worden geladen. Actieve mixed content is veel gevaarlijker, omdat een gemanipuleerd script inloggegevens kan stelen, de gebruiker kan omleiden of malware in de pagina kan injecteren. Alle moderne browsers blokkeren actieve mixed content standaard. De bron wordt simpelweg niet geladen, wat de paginafunctionaliteit volledig kan breken.

Hoe browsers omgaan met mixed content

Het browsergedrag is in de loop der jaren strenger geworden. Dit is wat er vandaag gebeurt:

• Chrome: blokkeert alle actieve mixed content. Sinds versie 80 upgradet Chrome ook automatisch mixed afbeeldingen, audio en video naar HTTPS. Als de HTTPS-versie niet bestaat, wordt de bron geblokkeerd.
• Firefox: blokkeert actieve mixed content en toont een schildpictogram in de adresbalk. Passieve mixed content veroorzaakt een waarschuwing, maar kan in sommige gevallen nog worden geladen.
• Safari: blokkeert actieve mixed content. Passieve mixed content kan met een waarschuwing worden geladen, afhankelijk van de versie.
• Edge: volgt hetzelfde Chromium-gebaseerde gedrag als Chrome.

De trend is duidelijk: browsers gaan over op het blokkeren van alle mixed content, zowel actief als passief. Het oplossen van mixed-contentproblemen is niet langer optioneel.

Bronnen van mixed content vinden

Er zijn verschillende manieren om mixed content op uw WordPress-site te identificeren:

• Browser DevTools-console: open Chrome DevTools (F12), ga naar het tabblad Console en zoek naar gele waarschuwingen of rode fouten over mixed content. Chrome vertelt u precies welke bron-URL het probleem veroorzaakt.
• Why No Padlock: een gratis online tool (whynopadlock.com) die een URL scant en alle gevonden onveilige bronnen op de pagina opsomt. Handig voor een snelle controle zonder DevTools te openen.
• InspectWP-rapporten: InspectWP scant uw pagina automatisch op alle bronnen die via HTTP worden geladen op een HTTPS-pagina en somt elke bron op. Dit is de snelste manier om een volledig beeld te krijgen van uw hele site.
• SSL Labs: hoewel het in de eerste plaats een SSL/TLS-configuratiecontrole is, kan het ook mixed-contentproblemen op de geteste pagina markeren.

Veelvoorkomende oorzaken van mixed content in WordPress

Mixed-contentproblemen in WordPress komen meestal van een paar terugkerende bronnen:

• Hardgecodeerde HTTP-URL's in inhoud: als u uw site van HTTP naar HTTPS hebt gemigreerd, kunnen uw oude berichten en pagina's nog steeds afbeeldings-URL's en links bevatten die beginnen met http://. Deze waren toen correct, maar werden mixed content na de migratie.
• Oude thema-assets: sommige oudere thema's of childthema's hebben hardgecodeerde HTTP-URL's in hun CSS, JavaScript-bestanden of templatebestanden. Een stylesheet die een achtergrondafbeelding laadt vanaf http://example.com/bg.jpg creëert mixed content.
• Plug-inbronnen: plug-ins die externe scripts of stijlen via HTTP laden, veroorzaken mixed content. Dit komt vooral vaak voor bij oudere of slecht onderhouden plug-ins die niet zijn bijgewerkt voor HTTPS.
• Externe embeds: iframes, ingesloten video's of widgets van externe diensten die HTTP-URL's gebruiken. Als de externe dienst HTTPS ondersteunt (de meeste doen dat tegenwoordig), lost het overschakelen van de URL naar HTTPS dit op.
• CDN-configuratie: als uw CDN niet is geconfigureerd om assets via HTTPS te leveren, wordt elk CSS-, JS- en afbeeldingsbestand dat via het CDN wordt geleverd, mixed content.

Mixed content in WordPress oplossen

De oplossing hangt af van de bron van het probleem. Hier zijn de meest voorkomende oplossingen:

• URL-vervanging in de database: gebruik voor hardgecodeerde HTTP-URL's in berichtinhoud een zoek-en-vervangtool om alle gevallen van http://uwdomein.com bij te werken naar https://uwdomein.com in de database. De plug-in Better Search Replace wordt hier veel voor gebruikt. Hiermee kunt u wijzigingen bekijken voordat u ze toepast en werkt deze in alle databasetabellen. Maak altijd een databaseback-up voordat u een zoek-en-vervangactie uitvoert.
• SSL Insecure Content Fixer: deze WordPress-plug-in lost onveilige URL's automatisch on-the-fly op. Het herschrijft HTTP-URL's naar HTTPS in de pagina-uitvoer zonder de database te wijzigen. Dit is een goede tijdelijke oplossing terwijl u de hoofdoorzaken aanpakt, maar het voegt een kleine prestatie-overhead toe omdat het elke paginalading verwerkt.
• Really Simple SSL: een andere populaire plug-in die de overgang van HTTP naar HTTPS afhandelt. Het lost mixed content op door de pagina-uitvoer te filteren, stelt redirects in en werkt de WordPress-site-URL-instellingen bij.
• Handmatige thema- en plug-incorrecties: als de mixed content afkomstig is uit een thema- of plug-inbestand, bewerk dan de broncode om http:// te vervangen door https:// of, beter nog, gebruik protocolrelatieve URL's (//example.com/file.js) of de WordPress-functie esc_url() om URL's dynamisch te genereren.

URL-vervanging in de database in detail

De grondigste manier om mixed content uit oude berichtinhoud op te lossen, is een zoek-en-vervangactie in de database. Hier is het proces:

1. Maak een back-up van uw database. Dit is niet optioneel; een verkeerde zoek-en-vervangactie kan uw hele site stuk maken.
2. Installeer en activeer de plug-in Better Search Replace.
3. Zoek naar http://uwdomein.com en vervang door https://uwdomein.com.
4. Selecteer alle databasetabellen (vooral wp_posts, wp_postmeta en wp_options).
5. Voer eerst een testrun uit om te zien hoeveel vervangingen er zouden plaatsvinden.
6. Als de aantallen er goed uitzien, voert u de daadwerkelijke vervanging uit.

Voor WP-CLI-gebruikers doet de opdracht wp search-replace 'http://uwdomein.com' 'https://uwdomein.com' --all-tables hetzelfde vanaf de opdrachtregel. WP-CLI verwerkt geserialiseerde gegevens in de database correct, wat cruciaal is voor opties en widgetinstellingen.

HTTPS-redirect via .htaccess

Zorg er na het oplossen van mixed content voor dat alle HTTP-verzoeken aan uw site worden omgeleid naar HTTPS. Dit voorkomt dat bezoekers en zoekmachines toegang krijgen tot de HTTP-versie. Voeg op Apache-servers deze regels toe aan uw .htaccess-bestand:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Voeg op Nginx-servers dit toe aan uw serverblok:

server {
    listen 80;
    server_name uwdomein.com www.uwdomein.com;
    return 301 https://$server_name$request_uri;
}

Deze redirect lost mixed content op zichzelf niet op, maar zorgt er wel voor dat niemand per ongeluk de HTTP-versie van uw site bezoekt. Gecombineerd met de URL-vervanging in de database en plug-incorrecties voltooit dit de HTTPS-migratie.

Wat InspectWP controleert

InspectWP scant uw pagina op alle bronnen die via HTTP worden geladen op een HTTPS-pagina en somt elke ervan op, inclusief het brontype en de volledige URL. Dit geeft u een duidelijke checklist van precies wat er moet worden opgelost. Pagina's zonder mixed-contentproblemen tonen een schoon resultaat, ter bevestiging dat uw HTTPS-opzet correct werkt.