Scanner voor gemengde inhoud

Hoe deze controle werkt

Scanaris leest de HTML van je over HTTPS geserveerde pagina en zoekt verwijzingen naar bronnen die beginnen met http://: scripts, stylesheets, iframes, afbeeldingen, video's, audio en lettertypen. Hij verdeelt ze in twee groepen. Actieve mixed content (scripts, stijlen, iframes) opent een bevinding met gemiddelde ernst, omdat die bronnen code kunnen uitvoeren of de pagina kunnen wijzigen. Passieve mixed content (afbeeldingen, video, audio) opent een bevinding met lage ernst: die voert niets uit, maar reist onversleuteld en breekt het slotje. Alleen verwijzingen in de initiële HTML worden onderzocht; bronnen die later via JavaScript worden toegevoegd, worden langs deze weg niet gezien.

Waarom dit belangrijk is

Een via HTTP geladen script in een HTTPS-pagina is het ergste geval: wie het netwerk beheert, kan het vervangen door een ander en in je pagina uitvoeren wat hij wil, met de sessie van de gebruiker. Daarom blokkeren moderne browsers het gewoon, en gaat je site op dat punt stilletjes kapot. Bij afbeeldingen laadt de browser ze wel, maar haalt hij het slotje weg of toont hij een waarschuwing "niet veilig", die de gebruiker ziet. In beide gevallen is de boodschap dezelfde: de pagina beweert veilig te zijn en is dat niet helemaal.

Waar het vandaan komt

Bijna altijd uit oude code: URL's gekopieerd uit een tutorial of template van jaren geleden, een bibliotheek gelinkt vanaf een CDN dat toen geen HTTPS had, afbeeldingen van een gemigreerde blog, of een databaseveld met de volledige URL van een afbeelding die werd geüpload toen de site nog op HTTP draaide. Bij WordPress is dit typisch na een overstap van HTTP naar HTTPS zonder de opgeslagen URL's bij te werken.

Hoe je het oplost

• Verander de verwijzingen naar https:// of naar relatieve paden (/images/foto.jpg), die het protocol van de pagina overnemen. Dat is de juiste en definitieve oplossing.
• Als een externe bron geen HTTPS heeft, download hem en serveer hem vanaf je eigen domein, of zoek een andere bron. In 2026 draait bijna niets legitiems nog alleen op HTTP.
• Bij WordPress werk je de in de database opgeslagen URL's bij met een zoek-en-vervangtool die serialisatie respecteert, en controleer je de site-URL's in de algemene instellingen.
• Als vangnet zegt de CSP-richtlijn upgrade-insecure-requests tegen de browser dat hij http://-verzoeken van je pagina automatisch naar https:// moet omzetten. Dat helpt terwijl je de code opschoont, maar vervangt het opschonen niet: de bron moet over HTTPS bestaan om dit te laten werken.

Content-Security-Policy: upgrade-insecure-requests

Controleer of het opgelost is

curl -s https://jouwdomein.nl | grep -oE '(src|href)="http://[^"]+"' | sort -u

Er mag niets uitkomen. Open daarna de pagina met de browserconsole: elke gemengde bron die via JavaScript wordt geladen, verschijnt daar als waarschuwing of blokkering.

Veelgestelde vragen

Mijn pagina laadt prima en heeft het slotje. Waarom wordt dit gemeld?

Omdat de browser de bron misschien stilletjes blokkeert of hem zelf naar HTTPS tilt. De verwijzing in je HTML blijft op http:// en andere clients (bots, oude browsers, e-mails) doen die correctie niet.

Zijn URL's die met // beginnen mixed content?

Nee. Protocolrelatieve URL's nemen het protocol van de pagina over en laden via HTTPS op HTTPS. Toch wordt tegenwoordig aangeraden direct https:// te schrijven.

Telt een link <a href="http://…"> mee?

Nee. Een link laadt niets in je pagina; hij brengt de gebruiker alleen ergens anders heen. Mixed content is wat de pagina zelf insluit.