Serhii LypiiHSTS preload list toevoegen is één van de weinige technische beslissingen op een website waar je vrijwel geen weg terug meer hebt. De preload-lijst is een hardcoded lijst in de bronnen van Chromium, Firefox en Safari; staat jouw domein er eenmaal in, dan weigert elke moderne browser vanaf de éérste request nog HTTP te spreken tegen jouw apex of subdomeinen. Dat is fantastisch tegen SSL-stripping en typosquatting, en pijnlijk als je een subdomein hebt dat je vergeten was op HTTPS te zetten. Dit artikel loopt de zes vereisten af, de submission-flow op hstspreload.org, en het testpad dat voorkomt dat je jezelf per ongeluk buitensluit.
Header-niveau werkt op elke stack identiek — WordPress, Laravel, Statamic, headless. HSTS is een response-header, geen CMS-feature.
Wat de preload-lijst eigenlijk is
Zonder preload doet HSTS het volgende: bij de éérste HTTPS-response ziet je browser een Strict-Transport-Security-header en onthoudt “voor dit domein: alléén HTTPS, voor X seconden”. De eerste request kán dus nog HTTP zijn — en juist daar zit een aanvalsraam voor SSL-stripping. De preload-lijst lost dat op door de HSTS-instructie vooraf in de browser-broncode te zetten. Dan is de eerste request al over HTTPS.
Dat is een defense-in-depth-laag boven op HSTS zelf. Preloaden is niet verplicht en niet altijd verstandig; wél verstandig zodra je infrastructuur er klaar voor is en je binnen twaalf maanden geen domeinwijziging voorziet.
HSTS preload list toevoegen: 6 eisen en de submission-flow
De 6 harde eisen voor submission
- Geldig HTTPS-certificaat op apex én alle subdomeinen. Elk subdomein dat DNS-technisch bestaat (
www,mail,dev,intranet) moet serveerbaar zijn over HTTPS met een geldig cert. Zelfs subdomeinen die je alleen intern gebruikt. - HTTP → HTTPS redirect met status 301 (permanent), niet 302. Op de apex én op alle subdomeinen. Een 302 wordt afgekeurd omdat browsers dan mogen speculeren dat de redirect tijdelijk is.
- Strict-Transport-Security header op de HTTPS-response, met exact:
max-age=31536000; includeSubDomains; preload. Demax-ageis minimaal 1 jaar (31 536 000 seconden).includeSubDomainsenpreloadmoeten allebei aanwezig zijn. - Alle subdomeinen serven over HTTPS. Ook
www, ook interne subdomeinen die niet publiek gebruikt worden. Als je eenstaging.ofdev.subdomein hebt zonder cert, faalt de submission — of erger, hij slaagt en die omgeving is onbereikbaar geworden. - Redirect vanaf de apex serveert de HSTS-header op de HTTPS-response. Bij een
www→apexredirect telt de header op de HTTPS-response van de apex zelf, niet op de redirect-response. - Geen mixed content op de site. Alle assets (afbeeldingen, scripts, styles, iframes) laden over HTTPS. Een enkel oud
<figure><img src="http://..."></figure>blokkeert nu al door de meeste browsers, maar preload eist een strikte HTTPS-hygiëne.
Controleer vooraf met een curl -I https://jouwdomein.nl en curl -I https://www.jouwdomein.nl of de header op beide responses aanwezig is. Aparte controle voor elk subdomein loont ook een minuut werk.
Submission-flow op hstspreload.org
De officiële hstspreload.org submission-tool is de enige route. Vul je domein in (zonder https:// prefix), klik op “check status” en wacht op de rij groene vinkjes. Rood is een blocker, geel is een waarschuwing die je submissie soms nog toestaat.
Zijn alle checks groen, dan klik je op “submit”. Vanaf dat moment zit je in de wachtrij. In mijn ervaring duurt het meestal 6 tot 12 weken voordat je in Chrome stable staat — Firefox en Safari volgen het Chromium-preload-bestand met eigen ritme, dus reken op enkele maanden voor volledige dekking.
Submission moet door de site-eigenaar zelf gebeuren; het is geen aanvraag die je door een derde partij laat regelen. Voor de definities van directives is de MDN-referentie voor Strict-Transport-Security de meest nauwkeurige bron.
Waarom dit een one-way door is
Verwijderen kán, via de “remove”-optie op hstspreload.org. Alleen: de removal-update moet nog in elke browser landen. Reken op maanden voordat dat via de nieuwe releases doorwerkt. In de tussentijd is elk subdomein zonder HTTPS onbereikbaar voor gebruikers die de oude preload-lijst nog in hun browser hebben zitten.
Concreet betekent dat: staat er over drie jaar plotseling een legacy intranet.jouwdomein.nl op HTTP, dan zijn eerst je collega’s met een oude Chrome-installatie de sigaar. Dat is geen ramp, maar wel een vervelend gesprek. Denk vooraf goed na of je binnen twaalf maanden een domeinwijziging, subdomein-uitbreiding of infrastructuurmigratie voorziet — dan is preloaden nu voorbarig.
Testroute voordat je submit
De veiligste route is stapsgewijs opschroeven van de max-age. Elk niveau is een terugkeerpunt: zolang je onder de één-jaar-grens en zonder preload-directive draait, kun je een fout terugdraaien binnen de dan geldende max-age.
- Stap 1:
max-age=300(5 minuten) — 24 uur draaien. Kort, laag risico. Alles wat kapot gaat, is snel weer normaal. - Stap 2:
max-age=86400(1 dag) — 1 week draaien. Nu heb je serieuze coverage van eerlijke gebruikers, maar rollback is binnen een dag mogelijk. - Stap 3:
max-age=31536000(1 jaar) +includeSubDomains— nog 1 week draaien. Dit is de stap waar de meeste sites falen: een vergeten subdomein zonder cert komt hier aan het licht. Los dat op vóór je verder gaat. - Stap 4: Voeg
preloaddirective toe en submit op hstspreload.org. Vanaf hier is de deur dicht.
Voor het rollback-scenario bij fouten in de eerste drie stappen: documenteer je stappen zoals je dat ook zou doen in een rollback-scenario bij fouten in een incident response plan. Datum, wijziging, verantwoordelijke, en de reden. Dat scheelt discussies bij een half incident.
Wanneer je NIET moet preloaden
Preloaden is niet altijd de juiste keuze. Vier scenario’s waarin je beter wacht of het bewust overslaat:
- Je hebt subdomeinen die je niet volledig controleert. Klant-subdomeinen (
klantnaam.jouwsaas.nl) waar de klant zelf een certificaat regelt, of white-label omgevingen. Eén niet-HTTPS-klant en je hebt een support-ticket-storm. - Staging op een subdomein van productie.
staging.jouwdomein.nlzonder publiek cert wordt onbereikbaar. Verplaats staging eerst naar een apart domein of zorg voor een geldig cert. - Domeinmigratie binnen 12 maanden op de planning. Migreer je binnenkort naar een nieuw domein, dan is preloaden op het oude domein onnodige lock-in. Doe het eerst op het nieuwe.
- Geen monitoring op certificaat-verlenging. Preload dwingt HTTPS af; als je Let’s Encrypt-renewal ooit stilstaat, is je site plotseling onbereikbaar in plaats van “onveilig”. Zorg eerst voor werkende monitoring en pas dan preloaden.
Voor context over de bredere set aan hardening-headers: zie ook de aanpak voor strengere security-headers op WordPress, waar CSP en HSTS elkaar aanvullen.
Snelle hulp — HSTS preload check en submission door Lypii
Wat ik meestal doe voor een klant die naar preload wil:
- Fix €70 — één-keer-check: header verifiëren op apex en
www, redirect-status controleren, submission voorbereiden. Voor een kleine site zonder bijzondere subdomeinen is dat vaak alles. - Support-abonnement €95 per maand — inclusief periodieke subdomein-audit. Vooral zinvol als je in groei zit en regelmatig nieuwe subdomeinen aanmaakt (
app.,api.,docs.). - Uur-tarief €105 — voor bredere audits, migraties, of als er meerdere domeinen met verschillende infra betrokken zijn.
Belangrijk: submission zelf moet door de site-eigenaar (jij of jouw beheerder) gebeuren via het hstspreload.org-formulier. Ik lever de checklist, de voor-controle en de rollback-strategie. Het klikken op “submit” is jouw beslissing.
Verbeteren boven herbouwen: dit is een header-fix op je bestaande site. Geen migratie, geen replatform.
Multi-stack opmerking: de aanpak is identiek op WordPress (via mu-plugin of .htaccess), Laravel (middleware), Statamic (config of .htaccess) en headless setups (edge worker of hosting-config). Verschillen zitten alleen in wáár je de header configureert, niet in wát de header moet zeggen.
Laadt je site nog HTTP-bestanden binnen een HTTPS-pagina, controleer dan eerst het stappenplan voor mixed content in WordPress oplossen.
