Website hardening in de praktijk: security headers, TLS en WordPress dichttimmeren
Deel dit artikel
In het kort
Hardening is geen losse trucjes maar vier lagen die op elkaar bouwen: transport (TLS), headers (browserregels), applicatie (WordPress/server) en proces (veilig uitrollen).
De meeste online gidsen geven je een config die je niet begrijpt en die je echte site breekt. Deze gids komt uit wat we élke dag op productie draaien — inclusief wat er misging.
Begin niet bij de moeilijkste laag. De juiste volgorde voorkomt downtime: eerst de headers die zelden iets breken, dan TLS, dan de applicatie, en de CSP als laatste — via report-only.
Onderaan elke laag verwijzen we naar de praktijk met onze exacte productieconfig.
Wat hardening wél en niet is
“Hardening” klinkt als iets eenmaligs — een knop die je omzet en klaar. Dat is het niet. Hardening is het systematisch verkleinen van je aanvalsoppervlak: elke functie die je niet gebruikt uitzetten, elke standaardinstelling die te ruim staat dichttrekken, en elke laag laten samenwerken zodat één gemiste fout niet meteen je hele site openlegt.
Het verschil tussen een gidsje en de praktijk zit in de details die niemand opschrijft: dat een strenge CSP je cookiebanner sloopt, dat HSTS-preload je subdomeinen buitensluit als die nog op HTTP draaien, dat een “veilige” XSS-header juist verouderd is. Daarom delen we hier niet de theorie, maar de configuratie die cobytes.com vandaag meestuurde — en de afwegingen erachter.
Laag 1 — Transport: TLS goed instellen
Alles begint bij de verbinding. Zonder strak ingerichte TLS maakt de rest niet uit: een aanvaller die tussen bezoeker en server zit, leest of wijzigt alsnog alles. Goede TLS betekent in 2026: TLS 1.3 aan, oude protocollen (TLS 1.0/1.1) uit, een verstandige cipher-volgorde, en OCSP stapling zodat de browser niet bij elke verbinding een trage certificaat-check hoeft te doen.
Daarbovenop dwing je HTTPS af met HSTS (Strict-Transport-Security), inclusief preload zodat zelfs de allereerste request al over HTTPS gaat. Wij draaien op cobytes.com max-age=31536000; includeSubDomains; preload — een jaar, alle subdomeinen, en aangemeld op de preloadlijst.
Security headers vertellen de browser wat wél en niet mag op jouw site: welke scripts mogen draaien, of de site in een <iframe> mag, welke API’s (camera, locatie) toegankelijk zijn. Goed ingesteld vangen ze het leeuwendeel van XSS, clickjacking en datalekken af — en ze kosten je niets aan performance.
Zeven headers doen het echte werk: HSTS, CSP, X-Content-Type-Options, frame-ancestors/X-Frame-Options, Referrer-Policy, Permissions-Policy en Cross-Origin-Opener-Policy. En één die je juist op 0 zet: X-XSS-Protection.
Laag 3 — Applicatie: WordPress en server dichttrekken
De sterkste headers helpen niet als je applicatie zelf lek staat. Op WordPress betekent hardening onder meer: de loginpagina afschermen, bestandsrechten correct zetten, wp-config.php beveiligen, een firewall op de server, en object-caching netjes scheiden. Stuk voor stuk maatregelen die wij standaard op elke beheerde site toepassen — als onderdeel van managed hosting.
Laag 4 — Proces: veilig uitrollen zonder je site te slopen
Dit is de laag die de meeste gidsen overslaan, en precies waar het misgaat. De krachtigste maatregel — een strenge Content-Security-Policy — is ook de gevaarlijkste om aan te zetten: één fout en je halve site doet het niet meer.
De oplossing is procesmatig: zet een nieuwe of strengere policy eerst in report-only. Die blokkeert niets, maar rapporteert wat er zou breken. Je laat ‘m meedraaien, loopt de rapporten leeg, en zet pas om naar enforce als de ruis nul is. Precies zo hebben wij cobytes.com naar een strict CSP gebracht: een nonce-based policy met 'strict-dynamic', zónder unsafe-inline of unsafe-eval. Het resultaat is een internet.nl-score van 100% en een plek in hun Hall of Fame.
Wie deze volgorde aanhoudt, bouwt op zonder verrassingen. Wie meteen bij laag 5 begint, zet de header binnen een dag weer uit.
Veelgestelde vragen
Is hardening eenmalig of doorlopend? Doorlopend. Nieuwe plugins, nieuwe marketingtools en nieuwe browserstandaarden veranderen je aanvalsoppervlak. Een policy die vandaag klopt, lekt over een half jaar als niemand ‘m bijhoudt. Daarom hoort hardening bij beheer, niet bij oplevering.
Kan ik dit zelf, of heb ik hulp nodig? De eerste lagen (headers die zelden iets breken) kun je prima zelf. TLS en vooral CSP op een productiesite met marketing- en CRM-tooling is een vak apart — daar zit het verschil tussen een mooie scanscore en een site die blijft werken.
Hoe meet ik waar ik nu sta? Stuur je site door securityheaders.com en SSL Labs. Dat geeft een eerste beeld van je headers en je TLS-configuratie.
Wil je dit in één keer goed? Bij security en managed hosting van Cobytes richten we alle vier de lagen in als onderdeel van het beheer — getest, op de webserver, en zonder je site te slopen. We passen dezelfde hardening toe die we op onze eigen infra draaien (ISO 27001 gecertificeerd).
keuzehulp
