--- title: "HSTS: wat het is en hoe je de header instelt" description: "HSTS (HTTP Strict Transport Security) is een beveiligingsheader die browsers dwingt een site alleen via HTTPS te openen." canonical: https://www.keurigonline.nl/begrippenlijst/hsts last_modified: 2025-12-18 --- [Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst) # HSTS HSTS (HTTP Strict Transport Security) is een beveiligingsheader die browsers dwingt een site alleen via HTTPS te openen. HSTS (HTTP Strict Transport Security) is een instructie van je webserver aan de browser om je site voortaan alleen via HTTPS te bezoeken. De browser onthoudt dat voor een vaste periode. Typt een bezoeker daarna http://jouwdomein.nl, dan maakt de browser er zelf https:// van. Je stelt HSTS in met de HTTP-header Strict-Transport-Security, bijvoorbeeld met de waarde max-age=31536000; includeSubDomains. De max-age staat in seconden, dus 31536000 is één jaar, en includeSubDomains laat de regel ook gelden voor al je subdomeinen. Komt de header via gewoon HTTP binnen, dan negeert de browser hem. HSTS beschermt tegen SSL-stripping, een aanval waarbij iemand op hetzelfde wifi-netwerk een HTTPS-verbinding ongemerkt in HTTP verandert. Een gewone redirect naar HTTPS houdt dat niet tegen. HSTS wel, omdat de browser het onveilige verzoek helemaal overslaat. Bovendien kan een bezoeker een certificaatfout dan niet meer wegklikken. Eén zwak punt blijft over: het allereerste bezoek. Daarvoor bestaat de HSTS-preloadlijst, die in grote browsers is ingebouwd. Aanmelden via hstspreload.org vraagt een max-age van minstens een jaar, plus includeSubDomains en preload. Een vermelding op die lijst terugdraaien duurt maanden, dus zet HSTS pas aan als al je subdomeinen goed via HTTPS werken. Op je hosting zet je de header bovenaan in het bestand .htaccess in public\_html, samen met een redirect van HTTP naar HTTPS. De regel ziet er zo uit: Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS. Begin gerust met max-age=300, vijf minuten, en verhoog de waarde stap voor stap zolang er niets breekt. Laat preload weg tot je je domein echt bij de preloadlijst wilt aanmelden. ## Geschiedenis HSTS bouwt voort op ForceHTTPS, een onderzoek uit 2008 van Collin Jackson en Adam Barth. In 2009 liet Moxie Marlinspike op Black Hat zien hoe makkelijk SSL-stripping werkt. Datzelfde jaar publiceerden Jeff Hodges (PayPal), Jackson en Barth het eerste ontwerp van de specificatie ([Wikipedia](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)). Belangrijke mijlpalen: - **2008:** Jackson en Barth beschrijven ForceHTTPS - **2009:** Moxie Marlinspike demonstreert SSL-stripping; op 18 september verschijnt het eerste HSTS-ontwerp - **November 2012:** HSTS wordt vastgelegd in [RFC 6797](https://datatracker.ietf.org/doc/html/rfc6797) - **Nu:** Chrome beheert de [HSTS-preloadlijst](https://hstspreload.org/); Firefox, Safari en Edge gebruiken lijsten die daarop zijn gebaseerd ## Bronnen 1. **IETF (2012)** - [RFC 6797 - HTTP Strict Transport Security (HSTS)](https://datatracker.ietf.org/doc/html/rfc6797) 2. **MDN Web Docs** - [Strict-Transport-Security header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) 3. **Chromium** - [HSTS Preload List Submission](https://hstspreload.org/) 4. **OWASP** - [HTTP Strict Transport Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) 5. **Wikipedia** - [HTTP Strict Transport Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) ## Gerelateerde artikelen Beveiliging 2 jul 2026 [HSTS-header inschakelen op gedeelde hosting: .htaccess-stappenplan](https://www.keurigonline.nl/blog/hsts-header-inschakelen-op-gedeelde-hosting) **Samenvatting: HSTS-header inschakelen op gedeelde hosting** Een SSL-certificaat alleen sluit de SSL-stripping gap niet: het eerste HTTP-verzoek blijft onbeveiligd totdat de redirect plaatsvindt. HSTS dicht dat gat door de browser te vertellen altijd HTTPS te gebruiken, nog vóór er verbinding wordt gemaakt. Je activeert het met twee regels in `.htaccess`, ook zonder root-toegang. Bouw de `max-age` stapsgewijs op (300 seconden naar 1 jaar) om jezelf niet buiten te sluiten, en meld je pas aan bij de HSTS preload list als alle subdomeinen permanent op HTTPS draaien. Beveiliging 29 jun 2026 [Website beveiligen tegen AI-phishing: stappenplan voor 2026](https://www.keurigonline.nl/blog/website-beveiliging-phishing-ai) Een Web Application Firewall (WAF) filtert kwaadaardig verkeer voordat het je applicatie bereikt. Voor WordPress: Wordfence of Cloudflare (gratis tier volstaat voor de meeste MKB-sites). Concrete instellingen: rate-limiting op `/wp-login.php` (maximaal 10 verzoeken per minuut per IP) en blokkeer `/xmlrpc.php` voor niet-API-clients. WAF biedt ook *virtual patching*: een kwetsbare plugin is al beveiligd op firewallniveau, nog voor de update uitkomt. ### Content Security Policy: stop XSS aan de bron Een Content Security Policy (CSP) vertelt de browser welke scripts en bronnen geladen mogen worden. Begin met de header `Content-Security-Policy-Report-Only` om schendingen te loggen zonder de site te breken. Scherp daarna geleidelijk aan. Aanvullende security headers voor HSTS, X-Frame-Options en Referrer-Policy voeg je toe via `.htaccess`. Kant-en-klare snippets vind je in ons overzicht van [20 .htaccess code snippets](https://www.keurigonline.nl/blog/20-htaccess-code-snippets-voor-snellere-websites). ### WordPress-specifieke maatregelen WordPress drijft 43% van het internet en ontvangt daardoor 90.000 geautomatiseerde aanvallen per minuut. Drie directe acties: verberg de standaard wp-admin-URL, schakel XML-RPC uit voor niet-API-clients, en installeer alleen plugins uit de officiële WordPress.org-repository. Combineer dit met een actueel beveiligingsbeleid voor snelheid en beveiliging, zoals beschreven in ons artikel over [WordPress sneller maken in 2026](https://www.keurigonline.nl/blog/wordpress-sneller-maken). Beveiliging 22 jun 2026 [MKB website beveiliging checklist 2026: praktische roadmap](https://www.keurigonline.nl/blog/mkb-website-beveiliging-checklist-2026) 96% van alle WordPress-kwetsbaarheden bevindt zich in plugins, niet in de core.[\[9\]](https://hidemywpghost.com/wordpress-security-statistics-2025-2026-43-verified-data-points/) Elke inactieve plugin die je deactiveert maar niet verwijdert, blijft een aanvalsvlak: de bestanden staan nog op de server. Verwijder alles wat je niet actief gebruikt, inclusief standaard meegeleverde thema's. ### 4. Beveiligingsheaders instellen 93,2% van alle WordPress-sites mist essentiële beveiligingsheaders zoals HSTS, CSP en X-Frame-Options.[\[2\]](https://guardingwp.com/research/state-of-wordpress-security-2026) Voeg ze toe via je webserverconfigatie of via een WordPress-plugin zoals Headers Security Advanced. Deze headers voorkomen clickjacking, cross-site scripting en het ongewenst inladen van je pagina in een iframe. Lees voor de technische achtergrond ook ons artikel over [hoe DNS je veiligheid beïnvloedt](https://www.keurigonline.nl/blog/dns-snelheid-veiligheid-website): DNSSEC en e-mailbeveiliging (DMARC/DKIM/SPF) horen bij dezelfde onderhoudsronde. ### 5. Internet.nl gratis scan uitvoeren Ga naar [internet.nl](https://internet.nl/) en voer je domeinnaam in. De gratis scan test HTTPS-configuratie, beveiligingsheaders, DNSSEC, DMARC/DKIM/SPF en IPv6. Van de 860.000 geteste domeinen haalt slechts 4,1% een perfecte score.[\[15\]](https://internet.nl/) Er is dus bijna altijd iets te verbeteren. Werk elk rood vinkje in de uitslag één voor één weg.