Gemengde inhoud na overstap naar HTTPS opsporen

Gemengde inhoud betekent dat een pagina via https laadt, maar sommige onderdelen (afbeeldingen, scripts, stijlbladen, frames) via http ophaalt. Wat de browser daarmee doet, verschilt per type onderdeel en per browser, en kan na een update veranderen. Een hangslot of waarschuwing in jouw browser is dus een momentopname van één pagina. Het zegt niets over de pagina's die je niet opende, over de pagina die pas na toestemming voor cookies extra scripts laadt, of over de versie die een bezoeker met een ander apparaat krijgt.

De beveiligingsdocumentatie van MDN op https://developer.mozilla.org/en-US/docs/Web/Security noemt als kernpraktijk dat je alle pagina's én alle onderdelen die ze laden via HTTPS aanbiedt. Dat is je doel: niet 'het slot staat er', maar 'geen enkel onderdeel wordt nog via http gevraagd'.

Zoek niet alleen in de zichtbare pagina. De meeste restanten zitten op plekken die je bij de migratie niet bekeek:

• Inhoud die redacteurs jaren geleden in de editor plaatsten en die in de database nog een volledige http-url bevat.
• Thema- en sjabloonbestanden met vaste adressen voor logo, favicon of lettertype.
• Stylesheets met achtergrondafbeeldingen of lettertypes via een absolute http-url.
• Het srcset-attribuut van afbeeldingen, waar één kandidaat-url kan afwijken van de rest.
• Ingesloten frames voor video's, kaarten of formulieren van derden.
• Scripts van derden, direct in de pagina of via een tagbeheerder, waaronder tellers, chatwidgets en advertentiecode.
• Instellingen in plugins of een CMS, bijvoorbeeld een veld met het 'site-adres' dat nog op http staat.

Verwijzingen in canonical-tags, sitemap en gestructureerde data zijn zelf geen gemengde inhoud, maar horen in dezelfde ronde mee op consistentie gecontroleerd te worden.

1. Stel een steekproef samen met één url per paginatype: startpagina, categorie, detail, blogbericht, formulier, bedankpagina, en een oude pagina uit het archief.
2. Open elke url in een privévenster. Bekijk in de ontwikkelaarstools van je browser het consolevenster en het netwerkvenster, en filter op 'http:'. Herhaal dit op mobiel formaat.
3. Doorzoek de broncode van de pagina op 'http://'. Noteer ook verwijzingen die pas na een klik, scroll of toestemming laden: accepteer en weiger de cookiemelding en vergelijk.
4. Laat een crawler het hele domein doorlopen die ook afbeeldingen, scripts en stijlbladen registreert, en filter de export op http-adressen. De steekproef toont patronen, de crawl toont omvang.
5. Doorzoek de database of een export van het CMS op je oude http-domein en op externe http-adressen.
6. Leg elke vondst vast in een tabel: pagina, onderdeel, type, plek van herkomst (inhoud, sjabloon, stijlblad, plugin, tagbeheerder) en wie het kan aanpassen.

Een crawl of steekproef vindt wat zichtbaar is in de gekozen toestand. Ingelogde pagina's, A/B-varianten en scripts die later nog extra scripts laden, kunnen ontsnappen. Noteer dus ook wat je niet hebt getest.

Voor scripts van derden raadt MDN daarnaast Subresource Integrity aan, zodat de browser controleert of het opgehaalde bestand overeenkomt met wat je verwachtte. Het vergt een controlesom die bij elke wijziging van het externe bestand moet worden bijgewerkt, dus bespreek dat met degene die het script beheert. Ook een Content Security Policy kan helpen, maar zet die eerst in een rapporterende modus en lees de meldingen vóór je iets afdwingt.

Test eerst op een testomgeving als je die hebt, en maak een back-up of een terugdraaiplan vóór je database-aanpassingen doet. Een zoek-en-vervang in de database is krachtig en kan serialiseerde gegevens beschadigen, dus laat de beheerder van het CMS bevestigen welke methode veilig is.

• Herhaal exact dezelfde steekproef en dezelfde toestanden als bij de diagnose (privévenster, mobiel, cookies geaccepteerd en geweigerd).
• Controleer dat consolemeldingen over onveilige onderdelen weg zijn en dat het netwerkvenster geen http-aanvragen meer toont.
• Draai de crawl opnieuw en vergelijk de lijst met http-adressen voor en na.
• Controleer of afbeeldingen zichtbaar zijn, formulieren werken en tellers nog meten.
• Test een ingelogde pagina en een oude archiefpagina apart.

Een schone steekproef bewijst niet dat de hele site schoon is. Plan de crawl daarom periodiek opnieuw, zeker na een thema- of pluginupdate.

Fictief voorbeeld (alleen invoer en controles). Een productpagina op https laadt (a) een productfoto met een http-adres in de inhoud, (b) een lettertypestijlblad met een http-adres in het sjabloon en (c) een telscript met een http-adres via de tagbeheerder. Invoer: de url, de consolemeldingen en de lijst van het netwerkvenster. Verwachte controles: voor (a) de database zoeken en het adres aanpassen; voor (b) het sjabloonbestand aanpassen en in de testomgeving laden; voor (c) de container aanpassen en in de voorbeeldmodus testen. Daarna dezelfde url opnieuw bekijken en de crawl herhalen.

Let ook op wie wijzigingen mag doorvoeren. Google beschrijft op https://support.google.com/accounts/answer/185839 tweestapsverificatie als extra beveiligingslaag voor het geval je wachtwoord wordt gestolen. De bron zegt niets over gemengde inhoud; het is een eigen redactionele suggestie om bij je beheerder na te gaan hoe accounts met rechten op scripts of sjablonen beveiligd zijn. Bij werk- of schoolaccounts kunnen de stappen verschillen, dus laat de beheerder nakijken wat bij jullie van toepassing is.

Wil je zien welke publieke signalen je website toont, bijvoorbeeld over de https-opbouw van je pagina's? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige technische implementatie.