Zorgen dat je beveiliging goed ingesteld staat op je WordPress website is erg belangrijk als je jezelf wilt beschermen tegen hackers. Er zijn allerlei verschillende verbeteringen en best practices voor WordPress beveiliging die je kan implementeren om ervoor te zorgen dat je website goed dicht zit. Als je WordPress website HTTPS gebruikt, dan is één van de verbeteringen die we je aanraden het gebruiken van de HSTS beveiligingsheader. Deze kan je helpen met het voorkomen van ‘man-in-the-middle’ (MitM) aanvallen en het kapen van cookies.

Wat is HSTS (Strict Transport Security)?

HSTS staat voor HTTP Strict Transport Security, oftewel strikte HTTP transportbeveiliging, en werd in 2012 door IETF gespecificeerd binnen RFC 6797. Het is gemaakt als een methode om af te dwingen dat de browser veilige verbindingen gebruikt wanneer een site via HTTPS loopt. Het is een beveiligingsheader die je toevoegt aan je webserver en die terug te zien is in de response header als Strict-Transport-Security. HSTS is belangrijk omdat het de volgende problemen aanpakt:

  • Alle pogingen van bezoekers om de onbeveiligde versie (HTTP://) van een pagina op je site te gebruiken zullen automatisch doorgestuurd worden naar de beveiligde versie (HTTPS://).
  • Sites waarvan de HTTP versie is opgeslagen in favorieten en mensen die zelf de HTTP versie van je site intypen, maken je kwetsbaar voor Man-in-the-middle aanvallen. Dit zijn aanvallen waarbij de aanvaller communicatie tussen twee partijen (bijvoorbeeld je site en de bezoeker) verandert en ze allebei laat geloven dat ze nog met elkaar communiceren.
  • Zo wordt het onmogelijk om de melding van een ongeldig certificaat te negeren, waardoor de bezoeker beschermd wordt.
  • Cookie-kaping: Dit kan gebeuren doordat iemand een sessiecookie steelt via een onbeveiligde verbinding. Cookies bevatten allerlei belangrijke informatie, zoals creditcardgegevens, namen, adressen, etc.

Zo voeg je HSTS toe aan je WordPress website

Technisch gezien voeg je HSTS eigenlijk toe aan de webserver zelf, die het vervolgens toepast op de HTTP verzoeken naar je WordPress website. Meestal wordt er een 301 redirect toegevoegd wanneer je een redirect van HTTP naar HTTPS wil toevoegen. Google heeft zelfs officieel bevestigd dat je zowel 301 server redirects als de HSTS header kan gebruiken, of allebei.

Alhoewel onze systemen standaard een voorkeur hebben voor de HTTPS versie, kan je dit ook duidelijker maken voor andere zoekmachines door ze door te sturen van je HTTP site naar je HTTPS versie en door de HSTS header te implementeren op je server. Zineb Ait Bahajji, Google Security Team

Er zijn verschillende typen directives en niveaus van beveiliging die je kan toepassen in de HSTS header. Hieronder staat de meest eenvoudige, deze gebruikt een max-age directive. Dit betekent een directive voor de maximale leeftijd, en definieert een tijd in seconden voor hoelang een webserver alleen via HTTPS mag leveren.

Inschakelen van HSTS in Apache

Voeg de volgende code toe aan je virtual hosts bestand.

Header always set Strict-Transport-Security max-age=31536000

Inschakelen van HSTS in NGINX

Voeg de volgende code toe aan je NGINX config.

add_header Strict-Transport-Security "max-age=31536000";

Als je een klant van Kinsta bent en je wil de HSTS header toevoegen aan je WordPress website, dan kan je een supportticket openen, en dan voegen we het zo voor je toe. Je website wordt zelfs wat sneller van het toevoegen van de HSTS header. Als iemand voortaan je website probeert te bereiken via HTTP, wordt er geen HTTP verzoek meer gemaakt, maar wordt alles meteen doorgestuurd naar de HTTPS versie.

Preload HSTS

Er bestaat ook HSTS preloading. Dit komt erop neer dat je je website en domein op een goedgekeurde HSTS lijst krijgt die in de browser is ingebouwd. Google stelt deze lijst samen en de lijst wordt gebruikt door Chrome, Firefox, Opera, Safari, Internet Explorer 11 en Edge. Stuur je site dus op naar de officiële HSTS preload lijst.

Preload HSTS
Preload HSTS

Je moet wel aan enkele voorwaarden voldoen om toegevoegd te kunnen worden.

  1. De server moet een geldig SSL/TLS certificaat hebben (TLS vs SSL: wat is het verschil?).
  2. Redirect al het verkeer naar HTTPS.
  3. Lever HSTS op het basisdomein.
  4. Lever alle subdomeinen af via HTTPS, vooral ook inclusief het www subdomein, als die bestaat.
  5. Verlooptijd moet tenminste 1 jaar zijn (31536000 seconden).
  6. De includeSubdomains token directive moet gespecificeerd zijn
  7. De preload token directive moet gespecificeerd zijn.

Om dit te doen moet je de verschillende subdomeinen en preload directives toevoegen aan je HSTS header. Hieronder zie je een voorbeeld van een bijgewerkte HSTS header.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Waarschuwing: Het kan nogal lastig zijn om je domein weer van de preload lijst af te krijgen, dus zorg ervoor dat je HTTPS echt voor de lange termijn gaat gebruiken voor dit domein.

Verifieer HSTS header

Er zijn verschillende eenvoudige manieren om te controleren dat HSTS inderdaad werkt op je WordPress website. Je kan Google Chrome Devtools starten, klik vervolgens op het tabblad ‘Network’ en kijk naar het tabblad headers. Zoals je hieronder voor de Kinsta website kan zien heeft die de HSTS waarde: “strict-transport-security: max-age=31536000” toegepast.

strict transport security http response

Je kan je WordPress website ook scannen met een gratis online tool, bijvoorbeeld securityheaders.io, waardoor je weet of je strict-transport-security header al dan niet toegepast wordt.

scan security headers

HSTS ondersteuning door browsers

Volgens Caniuse is de ondersteuning van HSTS door browsers erg sterk met 80% wereldwijd en meer dan 95% in de Verenigde Staten. Ondersteuning voor HSTS in Internet Explorer 11 werd toegevoegd in 2015 en momenteel is Opera Mini de enige moderne browser die het niet ondersteunt.

hsts browser support

We raden je aan om ook even dit artikel van Tim Kadlec te lezen over HSTS en Let’s Encrypt.

HSTS Impact op SEO

Nadat je website is goedgekeurd en opgenomen in de HSTS preload lijst, zul je wellicht waarschuwingen gaan krijgen in de Google Search Console of een andere SEO-tool over 307 redirects. Dit komt doordat iemand die nu je website probeert te bezoeken via HTTP een 307 redirect in de browser krijgt, in plaats van de eerdere 301 redirect (zoals hieronder te zien).

HSTS - Strict-Transport-Security 307 redirect
HSTS – Strict-Transport-Security 307 redirect

Over het algemeen wordt een 307 redirect alleen gebruikt voor tijdelijke redirects. Een 301 redirect gebruik je voor URL’s die permanent verhuisd zijn. Zou het dus geen 301 redirect moeten zijn? En wat zijn de SEO gevolgen hiervan?

In feite wordt er achter de (computer)schermen nog steeds een 301 redirect uitgevoerd. De 307 redirect wordt namelijk op het niveau van de browser uitgevoerd, niet bij de server. Je kan je website door een tool halen die de redirect op het niveau van de server controleert, bijvoorbeeld httpstatus, en dan zul je zien dat er inderdaad een 301 redirect wordt uitgevoerd. Je hoeft je daarom geen zorgen te maken dat de HSTS header een slechte invloed heeft op je SEO.

HSTS 301 redirect
HSTS 301 redirect