Contact
← Terug naar kennisbank DRUPAL

Drupal beveiligen — wat anders is dan WordPress

Drupal heeft een gunstigere uitgangspositie dan WordPress: kleiner attack-surface, granulaire permissies en een professioneel security-team. Maar precies daarom worden Drupal-sites die wél lek zijn vaak hárder geraakt. Dit zijn de tien stappen die het verschil maken.

14 min lezen · Laatst gecheckt:

Wie Drupal beheert na jaren WordPress doen, merkt het verschil snel. Drupal heeft kleinere distributie (≈1.5% van het web tegen WordPress' 43%), wat betekent: minder geautomatiseerde scans op jouw site. Maar Drupal-sites zijn vaker enterprise — overheid, universiteit, financieel — en dat maakt ze interessant voor gerichte aanvallen. De beveiliging vereist dus een andere mindset: niet "verdedigen tegen botnets", maar "verdedigen tegen mensen die specifiek jouw site bekijken".

Dit artikel veronderstelt Drupal 9 of 10 (Drupal 7 is sinds januari 2025 End of Life — als je daar nog op zit, is updaten je #1 prioriteit, niet hardenen). De principes gelden ook voor Drupal 11.

Update 2026: Drupal-sites in de semi-publieke en overheidssector zijn dit jaar zichtbaar vaker doelwit. Ook als individuele incidenten niet de pers halen, vormen organisaties die op Drupal draaien — gemeenten, universiteiten, zorginstellingen — een geliefd target. De combinatie van waardevolle data en strikte AVG-meldingsplicht maakt elk incident kostbaar. Hardening is geen optionele excellence meer, maar bedrijfsvoering hygiëne.

Hoe Drupal verschilt van WordPress qua security

Een paar fundamentele verschillen vóór we de stappen ingaan:

  • Permissions: Drupal heeft tientallen granulaire permissies per content-type (create, edit own, edit any, delete own, delete any). WordPress heeft 5 hoofdrollen. Drupal vereist meer denkwerk maar geeft ook fundamenteel betere control
  • Modules vs plugins: Drupal-modules zijn meestal kleiner van scope en strikter peer-reviewed. Drupal.org heeft een formele Security Advisory Coverage policy die niet elke module krijgt
  • Updates: standaard via Composer en Drush, niet via de UI. Vereist meer technische kennis maar geeft veel meer controle
  • Twig templates: sinds Drupal 8 mag PHP niet meer in templates — dit elimineert hele klasse van XSS-aanvallen die WordPress nog wél heeft
  • Configuratie: configuratie staat in YAML-files (config sync), niet in database. Voorkomt drift en maakt code-review van wijzigingen mogelijk

1. Updates — abonneer op Security Advisories

De Drupal Security Team publiceert formele advisories met SA-nummers (zoals SA-CORE-2024-001). Updates komen op vaste woensdagen — meestal de derde van de maand. Cruciaal:

  • Abonneer op de mailinglist: drupal.org/security
  • Volg @drupalsecurity op Twitter/X voor real-time meldingen
  • Update binnen 24-48 uur bij Highly Critical advisories — die krijgen vaak binnen een week ge-exploited

Voor de updates zelf: gebruik Composer + Drush, niet de UI:

# Update Drupal core
composer update drupal/core "drupal/core-*" --with-all-dependencies

# Update alle modules
composer update

# Database updates uitvoeren
drush updb -y

# Cache rebuilden
drush cr

Test elke update altijd eerst op staging (zie het staging-artikel — principes gelden ook voor Drupal).

2. Verwijder ongebruikte modules — niet alleen disable

"Uninstalled" in Drupal verwijdert de configuratie maar laat de code staan. Voor security: gebruik Composer om de hele module weg te halen.

# Module uninstallen (verwijdert config)
drush pmu module_name -y

# Module compleet verwijderen via Composer
composer remove drupal/module_name

Specifiek opletten:

  • Test- en demo-modules uit ontwikkelfase
  • Devel module — uitschakelen op productie (geeft veel info aan aanvallers)
  • Update Manager — als je via Composer werkt, niet meer nodig en heeft historisch kwetsbaarheden gehad
  • Modules die "Not covered by security advisory policy" zijn (zie stap 4)

3. settings.php hardening — vier essentiële regels

Het belangrijkste configuratie-bestand. Vier dingen moeten goed staan:

3.1 — trusted_host_patterns

Voorkomt host header injection-aanvallen. Drupal accepteert standaard requests voor élke hostname als deze instelling ontbreekt:

$settings['trusted_host_patterns'] = [
    '^jouwsite\.nl$',
    '^www\.jouwsite\.nl$',
];

Geen trusted_host_patterns? Dan kan een aanvaller de site benaderen met een nep Host-header en je site dwingen om links naar zijn server te genereren in password-reset mails (account takeover).

3.2 — hash_salt

Wordt gebruikt voor het signen van one-time login links, password reset links en sessions. Genereer een echt willekeurige string van 50+ karakters:

$settings['hash_salt'] = 'lange-willekeurige-string-met-veel-entropie-hier-50-tekens-of-meer';

Bij een gehackte site: vervang deze waarde — alle bestaande sessies worden ongeldig en lopende password-reset links werken niet meer. Effectief alle aanvallers worden uitgelogd.

3.3 — Configuratie file_scan_ignore_directories

Voorkomt dat Drupal grote vendor-mappen scant (en mogelijk uitvoert):

$settings['file_scan_ignore_directories'] = [
    'node_modules',
    'bower_components',
];

3.4 — Reverse proxy / TrustedHosts

Draait je Drupal achter een reverse proxy (Cloudflare, Varnish)? Configureer dan welke proxies vertrouwd zijn — anders kunnen aanvallers IP-headers spoofen:

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = ['10.0.0.1', '10.0.0.2'];

4. Modules alleen van drupal.org, met Security Advisory Coverage

Niet elke module op drupal.org krijgt security updates van het officiële Security Team. Sommige zijn "Not covered" — wijzigt het maintainer-vrijwilliger werk niet, dan krijg je geen security advisory. Bij elk module check:

  • Op de module-pagina staat onder "Maintenance status" / "Development status" of de module covered is
  • "Covered by Drupal's security advisory policy" = goed
  • "Not covered by Drupal's security advisory policy" = risico, vermijd voor productie

Modules van GitHub of obscure third-party sites: vermijd helemaal. Alleen drupal.org, of jouw eigen custom modules waarvan je elke regel kent.

Voor een audit van wat je hebt:

drush pm:list --status=enabled --format=table

Loop de output door en check elke module of die nog onderhouden wordt.

5. Bescherm /sites/default/files/ tegen PHP-uitvoering

Drupal levert standaard een .htaccess in /sites/default/files/ die PHP blokkeert:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<FilesMatch "\.(engine|inc|install|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svg)$|^(\..*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.swp|\.bak|_inc|inc|\.dist|orig|save)$">
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
</FilesMatch>

Maar check of die er nog staat — sommige migraties of file-cleanups verwijderen 'm per ongeluk. Bij een minimal install of custom setup: zelf opnieuw plaatsen. Zonder dit kan een aanvaller een PHP-bestand uploaden via een formulier en die direct uitvoeren.

Zelfde voor /sites/default/files/private/ als die bestaat.

Zie ook het .htaccess artikel voor algemene context over deze regels.

6. Granulaire permissies — geen "administrator"-rol als oplossing voor alles

De grootste WordPress-import-fout: redacteuren krijgen "administrator" rol omdat de granulariteit van WordPress te grof is. In Drupal kan en moet het anders.

Aanbevolen rol-structuur voor een typische zakelijke site:

  • Anonymous: alleen content bekijken (default)
  • Authenticated: idem, mogelijk + comments plaatsen
  • Editor: create + edit own + edit any (binnen specifieke content-types)
  • Reviewer: alleen edit any + publish (geen create — dwingt content-flow af)
  • Site Manager: configuratie van menus, blocks, taxonomies — maar GEEN module install of permissions wijziging
  • Administrator: alleen één account, alleen voor noodgevallen, met 2FA

De permissies "administer site configuration", "administer modules", "administer permissions" en "administer users" mogen uitsluitend bij echte admins liggen. Een gehackt editor-account is een verloren editor-account; een gehackt admin-account is een verloren site.

Audit je permissies:

drush role:list
drush user:role:list

7. Tweefactor-authenticatie via TFA module

De officiële TFA module (Two-Factor Authentication) ondersteunt:

  • TOTP (Google Authenticator, Authy, 1Password)
  • U2F / WebAuthn (hardware keys zoals YubiKey)
  • Recovery codes voor noodgevallen

Configureer als verplicht voor alle administratieve rollen. Editors mogen optioneel — admins niet.

Niet vergeten: backup recovery codes ergens veilig opslaan. Zonder die kun je jezelf permanent uitsluiten als je telefoon kwijt raakt.

8. Limit login attempts — Flood control

Drupal heeft ingebouwde flood-control voor login-pogingen, maar de defaults zijn vrij ruim. Verstrak via core.flood configuratie:

# Via drush config-set
drush cset core.flood ip_limit 50
drush cset core.flood ip_window 3600
drush cset core.flood user_limit 5
drush cset core.flood user_window 3600

Plus de Flood control module voor een UI om dit te beheren plus om geblokkeerde IP's te zien en handmatig te ontblokkeren.

9. Security Review module installeren

De officiële Security Review module doet een audit op je site:

  • File permissions zijn correct
  • Geen executable PHP in publieke directories
  • Standaard admin-account is verwijderd of hernoemd
  • Sterke wachtwoord-policy
  • Trusted host patterns is gezet
  • Error reporting is uit op productie
  • Filter formats zijn niet te ruim ingesteld

Draai 'm na elke major update — dingen kunnen accidenteel terug verkeerd worden gezet. Op productie module deactiveren tussen audits door (geeft veel server-info als 'ie aan staat).

10. Web Application Firewall (WAF)

Voor extra bescherming tegen geautomatiseerde aanvallen, drie opties:

  • ModSecurity met OWASP CRS: server-niveau, vaak standaard beschikbaar op shared hosting met DirectAdmin/Plesk. Vraag je hoster naar de specifieke ruleset
  • Cloudflare WAF: cloud-niveau, filtert vóór aanvallen je server bereiken. ~€10-20/maand per zone
  • Sucuri WAF: alternatief voor Cloudflare, meer Drupal-specifieke regels

Voor enterprise Drupal zit een WAF op cloud-niveau bijna altijd in de architectuur — dat is geen luxe, dat is hygiëne.

Bonus: backups, monitoring en hosting

De extra's die het verschil maken bij een incident:

  • Backups: dagelijks automatisch, naar externe locatie. Tools: Backup and Migrate module, of server-niveau backups via je hosting. Test minimaal jaarlijks of de restore werkt
  • File integrity monitoring: detecteer ongeautoriseerde wijzigingen aan code. Tools: aide, tripwire of een Drupal-specifieke monitor zoals Integrity module
  • Activity log: Database Logging staat standaard aan, maar log niet eindeloos veel. Voor langere retentie: ship logs naar een externe service (Loggly, Papertrail, ELK)
  • Hosting-keuze: Drupal-specifieke hosting (Pantheon, Acquia, Platform.sh) heeft security-defaults die generieke shared hosting mist. Voor enterprise sites zijn ze hun premium prijs vaak waard

Wat je niet hoeft te doen op Drupal

Een paar dingen die in WordPress-tutorials altijd voorkomen, maar in Drupal overbodig of zelfs schadelijk zijn:

  • Database-prefix wijzigen: niet nodig in Drupal — er zijn geen geautomatiseerde scans die op default tabel-namen mikken zoals bij WordPress (wp_users)
  • Admin-URL verbergen: /user/login en /user zijn standaard — wijzigen breekt veel. Beter: rate-limit + 2FA
  • PHP filter installeren: was tot Drupal 7 een module, in Drupal 8+ verwijderd uit core om security-redenen. Niet opnieuw installeren via contrib — gebruik Twig templates voor dynamische content
  • XML-RPC blokkeren: Drupal heeft geen XML-RPC in core (anders dan WordPress). Wel: check of je RESTful Web Services correct hebt geconfigureerd

Wanneer schakel je hulp in?

  • Drupal 7 site die nog draait — End of Life, moet ASAP naar Drupal 10/11 of een opvolger
  • Custom modules waarvan de oorspronkelijke ontwikkelaar niet meer beschikbaar is — security audit van eigen code
  • Site is gehackt en je weet niet hoe ze binnenkwamen
  • Multisite Drupal installation met gedeelde codebase — security in multisite is ander spel
  • Performance + security balans op enterprise schaal — caching strategieën die security raken (anonymous user cache vs authenticated user cache)
  • Migratie van Drupal 7 naar 10/11 — content-migratie is complex en heeft eigen security-implicaties

Drupal-security is niet moeilijker dan WordPress-security, maar wél anders. De overgang van "ik heb WordPress gedaan" naar "ik beheer een Drupal-site" vraagt om een andere mindset — meer code, minder klikken, granulairder denken. Het loont de moeite: een goed gehard Drupal-site staat fundamenteel sterker dan een goed gehard WordPress-site, juist door de architectuur.