Mixed content en HTTPS-fouten oplossen: stappenplan

Je hebt HTTPS ingesteld, maar toch laat de browser geen volledig veilige verbinding zien of verschijnt er een waarschuwing over onveilige onderdelen. Meestal komt dat door mixed content: een beveiligde HTTPS-pagina die stiekem nog bestanden over het onveilige HTTP laadt. In deze handleiding lees je wat mixed content is, waarom browsers het blokkeren en krijg je een stappenplan waarmee je mixed content en HTTPS-fouten leert oplossen, of je nu WordPress of een statische site gebruikt.

Wat is mixed content?

Mixed content ontstaat wanneer een pagina via HTTPS wordt geladen, maar losse onderdelen op die pagina nog via het onveilige HTTP worden opgehaald. Denk aan afbeeldingen, scripts, stylesheets, lettertypen, video's of iframes. De hoofdpagina is dan versleuteld, maar die onderdelen niet. Daardoor is de pagina niet meer volledig beveiligd, en dat is precies wat de browser wil voorkomen.

Een onderdeel dat over HTTP binnenkomt, kan onderweg worden meegelezen of aangepast door iemand die het netwerkverkeer onderschept, een zogeheten man-in-the-middle. Bij een script of stylesheet is dat extra riskant, want daarmee kan een aanvaller code op je pagina uitvoeren of de inhoud veranderen. De belofte van HTTPS, dat niemand kan meekijken of knoeien, geldt dan niet meer voor de hele pagina.

Voor HTTPS heb je een geldig SSL-certificaat nodig. Bij LJPc hosting krijg je dat gratis via Let's Encrypt, automatisch aangevraagd en vernieuwd zodra je domein naar de server wijst. Een certificaat alleen lost mixed content echter niet op, want de onveilige verwijzingen staan in de inhoud van je site zelf.

Actieve en passieve mixed content

Browsers verdelen mixed content in twee soorten en behandelen ze verschillend. Het verschil bepaalt of een onderdeel automatisch wordt opgewaardeerd of meteen wordt geblokkeerd.

Passieve (upgradebare) mixed content

Dit zijn onderdelen die alleen iets tonen en de rest van de pagina niet aansturen: afbeeldingen via het img-element, achtergrondafbeeldingen in CSS en geluid of video via de elementen audio, video en source. Moderne browsers proberen deze verzoeken automatisch te upgraden naar HTTPS. Lukt dat niet, dan wordt het onderdeel geblokkeerd. Er is geen terugval naar HTTP.

Actieve (blokkeerbare) mixed content

Dit zijn onderdelen die de hele pagina kunnen beïnvloeden: scripts, stylesheets via link, iframes, lettertypen en verzoeken via fetch of XMLHttpRequest. Ook afbeeldingen met een srcset en bronnen binnen een picture-element vallen hieronder. Deze onderdelen blokkeert de browser meteen, omdat het risico te groot is. Het gevolg is vaak een kapotte lay-out, ontbrekende functies of een pagina die er anders uitziet dan bedoeld.

Mixed content herkennen in de browser

Het slotje in de adresbalk is tegenwoordig een minder betrouwbare aanwijzing dan vroeger. Wat je precies ziet, verschilt per browser en per versie.

• In Chrome is het bekende slotje sinds versie 117 (september 2023) vervangen door een neutraal instellingen-icoon met twee schuifjes. Dat icoon zegt op zichzelf niets over mixed content.
• De melding "Niet veilig" verschijnt vooral bij pagina's die volledig over HTTP laden, niet altijd bij een enkel onveilig onderdeel op een verder beveiligde pagina.
• Firefox, Safari en Edge tonen elk hun eigen variant, en de details veranderen met bijna elke update.

Wil je zeker weten of er mixed content is, gebruik dan de ontwikkelaarsconsole van je browser (DevTools). Die is veel betrouwbaarder dan het pictogram in de adresbalk.

De oorzaak vinden met DevTools

De console van je browser wijst je precies naar het onveilige onderdeel:

1. Open de pagina en druk op F12, of klik met de rechtermuisknop en kies "Inspecteren".
2. Ga naar het tabblad Console.
3. Herlaad de pagina zodat alle onderdelen opnieuw worden geladen.
4. Zoek naar regels die beginnen met "Mixed Content".

De browser noemt per onderdeel de onveilige URL, bijvoorbeeld: Mixed Content: The page at 'https://jouwsite.nl/' was loaded over HTTPS, but requested an insecure resource 'http://...'. This request has been blocked. Zo weet je meteen welk bestand nog over HTTP wordt geladen. In het tabblad Netwerk (Network) kun je bovendien filteren op verzoeken en zie je welke bronnen via http:// binnenkomen.

Mixed content en HTTPS-fouten oplossen in WordPress

De meeste mixed content in WordPress komt door URL's die ergens hard met http:// zijn opgeslagen. Werk je site zo systematisch bij:

1. Controleer je site-URL. Ga naar Instellingen > Algemeen en zet zowel "WordPress-adres (URL)" als "Site-adres (URL)" op https://.
2. Vervang oude URL's in de database. Veel http://-links staan in berichten, pagina's en widgets. Met WP-CLI vervang je ze in één keer: wp search-replace 'http://jouwsite.nl' 'https://jouwsite.nl'. WP-CLI gaat correct om met geserialiseerde data. Maak eerst een back-up van je database.
3. Controleer hardgecodeerde verwijzingen. Kijk in je thema, in custom HTML-widgets en in menu's naar afbeeldingen, scripts of iframes die nog http:// gebruiken en pas ze aan.
4. Sla je permalinks opnieuw op. Ga naar Instellingen > Permalinks en klik op Wijzigingen opslaan om verwijzingen te verversen.

Wil je niet elke verwijzing los aanpassen, dan kun je de browser alle onveilige verzoeken automatisch laten upgraden met een beveiligingsheader. Die staat verderop beschreven.

Mixed content oplossen op statische sites

Bij een statische site of losse HTML-bestanden pas je de broncode direct aan. Zoek in je HTML en CSS naar http:// en vervang die verwijzingen door https://. Controleer vooral ingesloten content zoals video-embeds, kaarten, lettertypen en externe scripts, want daar zit mixed content vaak verstopt. Werkt een externe bron alleen over HTTP, zoek dan een variant die HTTPS ondersteunt of host het bestand op je eigen site.

HTTPS forceren via .htaccess

Als bezoekers je site ook nog via http:// kunnen openen, stuur je ze het beste automatisch door naar de HTTPS-versie. Zorg eerst dat je SSL-certificaat actief is, anders stuur je bezoekers naar een pagina die niet laadt. Op een Apache-server doe je de doorverwijzing met een paar regels in het .htaccess-bestand in de hoofdmap van je site:

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

Staat je site achter een loadbalancer of proxy, gebruik dan deze variant, die naar de doorgestuurde header kijkt:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Let op: een redirect stuurt alleen de hoofdpagina naar HTTPS. De onveilige verwijzingen naar afbeeldingen, scripts of stylesheets binnen die pagina blijven bestaan. Die pak je nog steeds aan in de inhoud zelf, of je laat ze upgraden met de header hieronder.

Alles in één keer upgraden met een beveiligingsheader

Heb je veel losse verwijzingen, dan is de header Content-Security-Policy: upgrade-insecure-requests een handig vangnet. Die vertelt de browser om alle http://-verzoeken op je pagina automatisch als https:// op te halen. Je stelt hem in als HTTP-header of als meta-tag in de head van je pagina:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Dit is een vangnet, geen vervanging voor het opschonen van je URL's: de bron moet wel echt via HTTPS bereikbaar zijn. Meer over dit soort headers lees je in het artikel over HTTP-beveiligingsheaders instellen.

Met deze stappen los je mixed content- en HTTPS-fouten meestal snel op: herken het probleem in de console, spoor de http://-verwijzingen op en pas ze aan in je CMS of bestanden. Kom je er niet uit? Neem dan contact op met onze support, dan kijken we met je mee.