• Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)
• Gezakt :Domeinnaam niet ondertekend (DNSSEC): Vraag je nameserver-beheerder (vaak je registrar en/of hostingprovider) om DNSSEC te activeren
• Gezakt :Verbinding niet of onvoldoende beveiligd (HTTPS) automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301
• Suggestie :Een of meer aanbevolen beveiligingsopties niet ingesteld (Beveiligingsopties) Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.
• Geslaagd :Geautoriseerde route-aankondiging (RPKI)

We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf 'upgraden' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

• http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
• http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie 'Webapplicatie-richtlijnen, Verdieping' van NCSC, richtlijn U/WA.05.

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina's. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

3. Begin met 5 minuten (max-age=300);

4. Verhoog dit naar 1 week (max-age=604800);
5. Verhoog dit naar 1 maand (max-age=2592000);

6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.