Hoe veilig is Drupal écht? Het Security Team, het disclosure-proces en wat jij nog moet regelen

Datalekken halen steeds vaker het nieuws. Wie een CMS-keuze moet verdedigen of een bestaande Drupal-site beheert, krijgt steevast dezelfde vraag: is dit veilig genoeg? Het antwoord begint bij het Drupal Security Team — een vrijwilligersgroep van 28 reguliere leden (plus 4 provisional members in inwerking) die sinds 2005 kwetsbaarheden in Drupal-core en bijgedragen modules coördineert, patches begeleidt en wekelijks advisories publiceert. Dat proces is publiek, voorspelbaar en auditable. Maar een CMS-framework alleen is nooit genoeg. Deze gids legt uit wat Drupal wél en niet voor je regelt — zonder paniek, met feiten en bronvermelding.

• Drupal heeft een officieel Security Team — 28 reguliere leden, actief sinds 2005.
• Security-releases verschijnen op vaste woensdagen. Je kunt je patch-window in de sprintplanning zetten.
• Kritieke issues worden 2-3 dagen vooraf aangekondigd via een Public Service Announcement (PSA) — uniek in CMS-land.
• Drupal is secure-by-default: Twig auto-escaping, CSRF-tokens, Form API-validatie en database-abstractie zitten in de kern.
• Een CMS dekt niet alles. Hosting, admin-accounts, phishing en supply-chain blijven jouw verantwoordelijkheid.

Bijna geen enkel CMS heeft dat — en daarin onderscheidt Drupal zich. Het Drupal Security Team is een publieke, vrijwilligersgestuurde werkgroep die sinds 2005 bestaat en wordt georganiseerd door de Drupal Association. Het team telt momenteel 28 reguliere leden verspreid over de wereld, aangevuld met 4 provisional members die nog in inwerkfase zijn en niet overal dezelfde toegang hebben. Zij komen uit agencies, hostingpartijen en de freelance-community, en worden georganiseerd door de Drupal Association. Zij triageren meldingen, coördineren patches met maintainers, schrijven advisories en beheren het embargo-proces. Alles staat gedocumenteerd op drupal.org/security-team en het security-archief.

Ter vergelijking: WordPress-core heeft een kleine security-werkgroep, maar 98% van het aanvalsoppervlak zit in plugins en thema's — en daar is geen gecoördineerd disclosure-proces voor. Joomla en TYPO3 hebben wel security-teams, maar zonder het PSA-mechanisme dat Drupal hanteert. Contentful is een SaaS-product — daar los je dit op met een contract, niet met community-processen.

Meldingen lopen via een gecoördineerd, privé-kanaal — zó voorkomt Drupal dat een exploit openbaar wordt voordat er een patch is.

1. Melding. Een beveiligingsonderzoeker mailt security@drupal.org of dient een issue in op het privé-deel van security.drupal.org.
2. Triage. Het Security Team valideert de melding, bepaalt de impact en beoordeelt of het core of contrib betreft.
3. Patch-ontwikkeling. De maintainer(s) schrijven een fix in een private repository. De CVSS-score wordt vastgesteld.
4. PSA (optioneel). Bij kritieke kwetsbaarheden (CVSS ≥ 7) publiceert het team 2-3 dagen vóór release een Public Service Announcement. Dit geeft beheerderstijd om teams stand-by te zetten.
5. Security Advisory (SA). Op de geplande woensdag verschijnt de SA met fix, versie-range en werkbare patch.
6. Publicatie & embargo-einde. Details en exploit-informatie komen pas later publiek, zodat traag-updatende sites niet direct onder vuur liggen.

Een SQL-injectie in de Database API maakte anonieme RCE mogelijk. Het Security Team bracht de patch uit binnen 7 uur na disclosure. Sites die de patch niet binnen 7 uur installeerden, moesten ervan uitgaan dat ze gecompromitteerd waren — de exploit werd letterlijk binnen enkele uren massaal gebruikt. Les: snelheid van patchen is voorspelbaar belangrijker dan de kwetsbaarheid zelf.

Een RCE in de Form API met CVSS-score 9.8. Het team publiceerde een PSA zes dagen vooraf, zodat hostingpartijen en beheerders konden mobiliseren. Toen de patch uitkwam, hadden miljoenen sites al een updateplan klaar. Les: het PSA-proces werkt, mits teams er bekend mee zijn.

Kleinere, gerichte SA's volgen de bekende cadans. Voor actuele voorbeelden raadpleeg je het volledige SA-archief. Het patroon blijft identiek: woensdag release, vooraankondiging bij kritieke impact, publieke post-mortem.

Drupal dekt structureel een aanzienlijk deel van de OWASP Top 10 in de kern af.

• Twig auto-escaping (sinds Drupal 8). Alle variabelen in templates worden standaard ge-escaped. Het overgrote deel van XSS-risico verdwijnt hiermee uit custom thema's.
• CSRF-tokens op alle formulieren via de Form API. Routes die state wijzigen, vereisen een geldig token.
• Form API-validatie. Server-side type-check, required-check en custom validators standaard afgedwongen.
• Database-abstractie. Alle queries lopen via de Database API met prepared statements. Raw SQL kan, maar is de uitzondering, niet de regel.
• Password hashing. Wachtwoorden worden sinds Drupal 7 gehashed met een PHPass-afgeleide; vanaf Drupal 10 wordt argon2id ondersteund.
• Trusted host patterns. Voorkomt host-header-injectie via expliciete configuratie in settings.php.

Deze dingen hoef je niet te bouwen — je hoeft ze alleen niet actief uit te zetten.

Security is het bekendste argument, maar Drupal heeft meer superkrachten die bij een enterprise-keuze zwaar wegen.

Patchen op vaste woensdagen betekent dat je operations-team capaciteit kan reserveren in plaats van ad-hoc brandjes te blussen. WordPress-core heeft een security-team, maar 98% van het attack surface (plugins) heeft geen vergelijkbaar proces. Een overheidsklant die ISO 27001 aan het doorlopen is, kan dit proces letterlijk in zijn incident-response-plan opnemen.

Drupal kent role-based permissions per content-type, per veld en per moderation-state. Scenario: een redacteur mag de productpagina bewerken behalve het prijs-veld, dat alleen een manager kan goedkeuren via content_moderation. WordPress kent native geen field-level permissions — je hebt plugins nodig die zelf onderhouden en beveiligd moeten worden.

Drupal behandelt content als getypeerde entities met velden, niet als HTML-blobs in de WYSIWYG. Eén productcatalogus met 30 attributen rendert zowel de listing, de detailpagina, een PDF-export én een mobile app via één bron van waarheid. In WordPress leeft dezelfde informatie vaak in ongestructureerde post-meta of custom fields — moeilijk te hergebruiken, moeilijk te valideren.

Native 100+ talen, per-veld-vertaling, fallback-chains en shared-codebase multi-site. Eén Europees bedrijf met 14 taal-/landvarianten draait op één codebase, met per-site contentteams en gedeelde bugfixes. TYPO3 komt in de buurt; WordPress vereist third-party plugins (WPML, Polylang) die hun eigen security-last met zich meebrengen.

Alle site-configuratie — content-types, velden, views, permissions, workflows — exporteert naar YAML en gaat door Git. Deploys zijn reproduceerbaar, auditable en reviewbaar. Voor WCAG-audits en ISO 27001-trajecten is dit gevalideerd goud. WordPress kent hier geen native antwoord op — configuratie leeft in de database.

Drupal heeft WCAG-compliance in de kern (admin UI én frontend-defaults), een actieve Accessibility Maintainers-werkgroep en automatische tests. Voor Nederlandse overheden (Besluit Toegankelijkheid) én EU-publieke-sector-sites (EAA 2025) is dat geen feature, maar wettelijke verplichting. Drupal levert dit structureel; de meeste alternatieven leggen het bij plugins of themes.

De Views-module zit in core. Redacteuren bouwen zelf gefilterde listings, archieven en zoekpagina's via de admin UI. Scenario: een nieuwe listing "projecten filteren op sector én jaar" is in Drupal een klus van 20 minuten. In WordPress is het een custom query-loop of een zware pagebuilder-plugin.

Eerlijk ook: Drupal wint niet overal. De leercurve is steiler dan WordPress, en het ecosysteem is kleiner. Voor een persoonlijke blog is Drupal overkill. Voor een structuurrijke organisatie met eisen op security, toegankelijkheid en meertaligheid is het vrijwel onverslaanbaar.

Wanneer kies je wat? 

• Persoonlijke blog of simpele brochure-site → WordPress. 
• Headless-first product met vast SaaS-budget → Contentful. 
• Complexe, meertalige, rechtensensitieve of overheidssite → Drupal of TYPO3.

Een CMS dekt ongeveer de helft van je aanvalsoppervlak. De andere helft moet je zelf regelen.

• Hosting-laag. Foute OS-versies, open poorten, onveilige PHP-configuratie — daar kijkt Drupal niet naar.
• Admin-accounts. Zwakke of gedeelde wachtwoorden, geen 2FA, ex-medewerkers met actieve accounts.
• Phishing naar redacteuren. Een getrainde redacteur is je grootste verdediging tegen credential-theft.
• Supply-chain via front-end. npm-pakketten in custom thema's, CDN-hijacks, gecompromitteerde build-pipelines.
• DDoS en CDN-misconfiguratie. Cloudflare of een WAF hoort voor je Drupal-site te staan.
• Dataclassificatie en DPIA. Drupal kan persoonsgegevens opslaan; dat legaal verantwoorden is een proces, geen module.

Wie dit erkent, bouwt een verdedigingsketen. Wie dit negeert, vertrouwt te veel op het CMS.

1. Update-policy: installeer security-releases binnen 72 uur, kritieke PSA-releases binnen 24 uur. 
2. Automatiseer notificaties via drupal.org/security/rss.
   settings.php hardening: stel trusted_host_patterns in, zet config_sync_directory buiten de webroot en beperk file_public_path correct.
3. Private files buiten webroot. Nooit private bestanden in /sites/default/files/ — altijd een niet-web-accessible pad.
4. Twee-factor-authenticatie voor alle admin-accounts. Drupal ondersteunt TOTP en WebAuthn via contrib.
5. HTTPS + HSTS + Content-Security-Policy headers. Niet alleen aanvinken; testen op securityheaders.com.
6. Backup-strategie met encryptie én geteste restore. Een backup die je nooit hebt teruggezet, is geen backup.
7. Contrib-module hygiene. Minimaliseer aantal modules, check dat ze onder "security advisory coverage" vallen, verwijder inactieve modules.

1. Geen update-logboek. Kun je niet aantonen wanneer welke security-release is geïnstalleerd? Dan is je compliance-verhaal zwak.
2. Een module die al zes maanden geen update heeft gehad. Óf stabiel, óf verlaten. In 9 van de 10 gevallen het laatste.
3. Geen staging-omgeving. Patchen op productie zonder test is Russisch roulette.
4. Geen incident-response-plan. "Wat doen we als we gehackt worden?" mag geen open vraag zijn als het gebeurt.
5. Geen security-monitoring. Je weet niet dat je gecompromitteerd bent tot een klant het je vertelt.

→ Ik heb een oude Drupal-site en maak me zorgen.
Start met een Drupal-audit. Je krijgt een gestructureerd rapport met bevindingen en prioritering.

→ Ik bouw een nieuwe website.
Begin met Drupal-development. Security, accessibility en config-as-code zijn vanaf dag één ingebakken.

→ Ik wil beheer en onderhoud volledig uitbesteden.
Dat regelen we via Drupal-onderhoud & support — inclusief hosting waar security-patches binnen de SLA vallen.

Draai je nog op Drupal 7? Dat is sinds januari 2025 end-of-life. Plan een Drupal-migratie — verder uitstellen maakt het risico alleen groter.

• Het Security Team bestaat sinds 2005 — langer dan Twitter.
• Dries Buytaert startte Drupal in 2001 vanuit zijn studentenkamer in Antwerpen, als prikbord voor studiegenoten.
• Drupal draait het whitehouse.gov-archief, NASA-afdelingen, Rijksoverheid.nl en grote delen van de Europese Commissie — mede omdat het security-proces auditable is.
• De woensdag als release-dag is gekozen omdat het in de VS én Europa een werkdag is én niet tegen het weekend aan zit — dus teams hebben tijd om te patchen vóór het weekend.
• Drupal.org zelf loopt op Drupal. De eigen site is testlab en paradepaardje tegelijk.