Hoe werkt de check?

Voor je developer · HTTPS / TLS

TLS versleutelt en authenticeert het verkeer tussen browser en server. Zonder geldig certificaat voor de hostnaam is er geen vertrouwelijkheid of integriteit, en tonen browsers een waarschuwing.

Installeer een geldig certificaat voor jouwbedrijf.nl (bijv. Let's Encrypt via ACME/certbot, of de optie in je hostingpanel)
en controleer dat de volledige certificaatketen wordt meegestuurd.

Voor je developer · HTTP → HTTPS-redirect

Verzoeken op poort 80 horen met een permanente redirect (301 of 308) naar de HTTPS-URL te gaan, zodat er nooit inhoud over onversleuteld HTTP wordt geserveerd.

Stuur alle http://-verzoeken met een 301 door. Bijvoorbeeld in nginx:

server {
  listen 80;
  server_name jouwbedrijf.nl;
  return 301 https://$host$request_uri;
}

Voor je developer · HSTS (Strict-Transport-Security)

De Strict-Transport-Security-header laat de browser voor de duur van max-age uitsluitend HTTPS gebruiken voor deze host. Dat voorkomt SSL-stripping. Advies: max-age van minimaal 180 dagen, liefst een jaar.

Strict-Transport-Security: max-age=31536000; includeSubDomains

(Voeg includeSubDomains alleen toe als álle subdomeinen HTTPS ondersteunen.)

Voor je developer · Mixed content

Actieve mixed content (scripts, stylesheets, iframes) wordt door browsers geblokkeerd, en een formulier dat naar http:// post geeft een waarschuwing. De CSP-directive upgrade-insecure-requests laat de browser zulke verzoeken automatisch via https doen.

Vervang http://-URL's door https:// (of relatieve URL's), en zet eventueel als vangnet:

Content-Security-Policy: upgrade-insecure-requests

Voor je developer · Content-Security-Policy (CSP)

CSP bepaalt waar scripts, styles en frames vandaan mogen komen en is de belangrijkste verdediging tegen XSS. Zonder script-src/default-src, met wildcards, of met 'unsafe-inline' zonder nonce of hash biedt het weinig bescherming.

Begin met Content-Security-Policy-Report-Only, verhelp de meldingen en zet het daarna aan, bijv.:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Voor je developer · Clickjacking (X-Frame-Options / frame-ancestors)

Zonder X-Frame-Options of CSP frame-ancestors kan elke website je pagina in een iframe laden (clickjacking / UI-redressing).

Content-Security-Policy: frame-ancestors 'self'

(of de oudere header: X-Frame-Options: SAMEORIGIN)

Voor je developer · X-Content-Type-Options: nosniff

nosniff zet MIME-sniffing uit, zodat de browser het opgegeven Content-Type volgt. Zo worden uploads of verkeerd getypeerde responses niet als script of stylesheet uitgevoerd.

X-Content-Type-Options: nosniff

Voor je developer · CMS-versie (WordPress, Joomla, Drupal …)

We herkennen het CMS aan de HTML van je homepage. Voor WordPress lezen we de core-versie uit de generator-tag of de core-assets en vergelijken die met de officiële lijst van wordpress.org (latest, outdated of insecure). Plug-ins en thema's controleren we niet: hun ?ver= zegt te weinig.

WordPress: Dashboard → Updates → Nu bijwerken (eerst een back-up), of met WP-CLI:

wp core update && wp plugin update --all && wp theme update --all

Laat automatische beveiligingsupdates aanstaan en houd plug-ins en thema’s ook bij.

Voor je developer · Versie-informatie in headers en HTML

Headers als Server en X-Powered-By, of <meta name="generator">, met versienummers maken fingerprinting en gerichte exploitatie eenvoudiger. Patchen blijft de echte oplossing.

nginx:     server_tokens off;
Apache:    ServerTokens Prod  en  ServerSignature Off
PHP:       expose_php = Off
WordPress: remove_action('wp_head', 'wp_generator');

Voor je developer · Cookie-attributen (Secure, HttpOnly)

Cookies zonder Secure kunnen over HTTP lekken. Sessiecookies zonder HttpOnly zijn via JavaScript uit te lezen (bij XSS). SameSite beperkt daarnaast CSRF.

Set-Cookie: naam=waarde; Path=/; Secure; HttpOnly; SameSite=Lax

Voor je developer · SPF-record

Het SPF-record (TXT, “v=spf1 …”) somt de servers op die mail mogen versturen voor dit domein. Ontvangende mailservers gebruiken het samen met DKIM en DMARC om spoofing te herkennen.

jouwbedrijf.nl  TXT  "v=spf1 include:<je-mailprovider> -all"

Microsoft 365:  include:spf.protection.outlook.com
Google:         include:_spf.google.com
Geen mail:      "v=spf1 -all"

Voor je developer · DKIM

DKIM (RFC 6376) ondertekent uitgaande mail; het publieke deel van de sleutel staat in DNS op <selector>._domainkey.<domein>. Gmail, Yahoo en Outlook.com eisen voor grote afzenders SPF én DKIM, met DMARC. Van buitenaf kunnen we alleen de gebruikelijke selectors proberen: de naam kiest je mailprovider.

Zet DKIM-ondertekening aan bij je mailprovider en publiceer het record dat die je geeft, bijvoorbeeld:

<selector>._domainkey.jouwbedrijf.nl  TXT  "v=DKIM1; k=rsa; p=<publieke sleutel>"

(of een CNAME naar je provider)

Voor je developer · DMARC-beleid

DMARC koppelt de SPF- en DKIM-uitkomst aan het From-domein en bepaalt het beleid: none (alleen meten), quarantine of reject. Met rua ontvang je rapporten over wie namens je domein mailt.

_dmarc.jouwbedrijf.nl  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@jouwbedrijf.nl"

Begin eventueel met p=none, lees de rua-rapporten en verhoog daarna naar quarantine en reject.

Voor je developer · DNSSEC

DNSSEC ondertekent DNS-records, zodat resolvers vervalste antwoorden (cache poisoning, spoofing) herkennen. We kijken of de validerende resolver 1.1.1.1 de AD-vlag (authenticated data) zet.

Activeer DNSSEC bij je DNS-provider en zorg dat het DS-record bij de registry staat (voor .nl: via je registrar bij SIDN).
Controleren:  dig +dnssec jouwbedrijf.nl SOA

Voor je developer · security.txt (RFC 9116)

Een /.well-known/security.txt met ten minste Contact en Expires geeft onderzoekers een vast meldpunt voor coordinated vulnerability disclosure.

Plaats op https://jouwbedrijf.nl/.well-known/security.txt:

Contact: mailto:security@jouwbedrijf.nl
Expires: 2027-10-26T00:00:00Z
Preferred-Languages: nl, en