Beveiliging afstemmen op Drupal

Response-headers (HSTS, referrer, permissions)

Twee van de headers die de check verwacht zet Drupal-core al: X-Content-Type-Options in de meegeleverde .htaccess, en X-Frame-Options: SAMEORIGIN op elke respons (sinds Drupal 8). Die kunnen dus al groen staan zonder dat je iets doet, en je hoeft ze niet nog eens te zetten (dat geeft een dubbele header). De overige (HSTS, Referrer-Policy, Permissions-Policy) zet je zelf: in de .htaccess, in de nginx-config, of via de contributed module Security Kit (seckit), die ze via een beheerscherm aanzet. HSTS werkt alleen over HTTPS.

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

De Content-Security-Policy

Een CSP is op Drupal lastiger omdat de core en veel modules inline scripts en styles toevoegen. Er is een contributed module, Content-Security-Policy (machinenaam csp), die de header genereert en de bronnen van je eigen libraries automatisch toevoegt; ingeschakeld levert die een report-only-header die overtredingen logt zonder te blokkeren. Security Kit kan een CSP ook zetten.

1. Zet de policy eerst in report-only (de Content-Security-Policy-Report-Only-header), dan breekt hij niets maar meldt hij wel wat hij zou blokkeren.
2. Verzamel de meldingen met een tool als Sentry, Report URI of URIports, of lees ze in je browserconsole.
3. Sta toe wat legitiem geblokkeerd wordt, tot er geen echte meldingen meer binnenkomen.
4. Hernoem de header naar Content-Security-Policy om de policy af te dwingen.

Cookies (Secure, HttpOnly, SameSite)

Drupal beheert de sessiecookie via Symfony, ingesteld in sites/default/services.yml onder session.storage.options. Sinds Drupal 10.1 staat SameSite standaard op Lax; je kunt Strict kiezen. HttpOnly staat standaard aan, en Secure hoort erbij zodra de site volledig over HTTPS draait. Bestaat er nog geen services.yml, kopieer dan default.services.yml. Voor de exacte sleutels van Secure en HttpOnly: kijk in default.services.yml in je installatie.

parameters:
  session.storage.options:
    cookie_samesite: Lax   # 'Lax' (default since D10.1), 'Strict', or 'None'

In de pagina (SRI, trackers na toestemming)

Een integrity-hash op een extern script zet je in de themalaag: in het Twig-template dat het script uitzet, of via een libraries.yml-definitie. Core heeft hier geen UI voor; er zijn contributed modules zoals External Script SRI die het beheren (voorbeeld, geen aanbeveling). Trackers pas na toestemming laden regel je met een consentmodule, bijvoorbeeld EU Cookie Compliance of Klaro, die scripts van derden tot toestemming blokkeert.

De verbinding (HTTPS afdwingen)

De standaard-.htaccess van Drupal bevat een kant-en-klaar redirectblok naar HTTPS dat is uitgecommentarieerd. Haal de # weg om al het HTTP-verkeer naar HTTPS te sturen. Op nginx regel je de redirect in de serverconfig. Achter een CDN of load balancer doe je dit vaak beter op dat niveau.

# Uncomment the next two lines to redirect to HTTPS.
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

DNS-records (SPF, DMARC, DNSSEC, IPv6)

Deze staan los van je site: het zijn records bij je domein. Je zet ze bij je DNS-provider of domeinregistrar, niet in je CMS of op je host. SPF en DMARC gaan over wie mail namens je domein mag sturen, DNSSEC ondertekent je DNS, en IPv6 is de enige waar de host eerst een AAAA-record en verbinding moet aanbieden voordat je die kunt zetten.