  1. [Home](/) /
2. [Blog](/blogs) /
3. Hoe veilig is Drupal écht? Het Security Team, het disclosure-proces en wat jij nog moet regelen
 
  Drupal · 17 Apr 2026 

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

Drupal heeft een officieel Security Team, vaste patch-woensdagen en secure-by-default. Lees hoe het werkt en welke 7 dingen je nog zelf 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](https://www.drupal.org/drupal-security-team/security-team-members) — 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.



 

 



 

 

 

## Heeft een CMS een eigen security-team?

 

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](https://www.drupal.org/security-team) en het [security-archief](https://www.drupal.org/security).

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.



 

 



 

 

 

## Zo werkt het disclosure-proces

 

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 ](mailto: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 &amp; embargo-einde. Details en exploit-informatie komen pas later publiek, zodat traag-updatende sites niet direct onder vuur liggen.



 

 



 

 

 

## Drie Drupal-security-momenten uit de geschiedenis

 

### Drupalgeddon (SA-CORE-2014-005, oktober 2014)

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.



 

 



### Drupalgeddon2 (SA-CORE-2018-002, maart 2018)

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.



 

 



### Recent (2024-2025)

Kleinere, gerichte SA's volgen de bekende cadans. Voor actuele voorbeelden raadpleeg je het volledige [SA-archief](https://www.drupal.org/security). Het patroon blijft identiek: woensdag release, vooraankondiging bij kritieke impact, publieke post-mortem.



 

 



 

 

 

## Secure by default: wat Drupal automatisch regelt

 

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.



 

 



 

 

 

## Waar Drupal écht in uitblinkt (en WordPress en andere CMS'en niet)

 

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



 

 



### 1. Officieel security-apparaat met voorspelbare cadans

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.



 

 



### 2. Granulaire rechten en workflows

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.



 

 



### 3. Structurele content-modellen (Entity API + fields)

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.



 

 



### 4. Meertaligheid en multi-site op enterprise-niveau

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.



 

 



### 5. Configuration management als code

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.



 

 



### 6. Accessibility als core-commitment

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.



 

 



### 7. Views: zoekresultaten bouwen zonder code

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.



 

 



 

 

 

## Drupal vs WordPress, Joomla, TYPO3, Craft, Contentful

 

### Security-dimensie

Dimensie

Drupal

WordPress

Joomla

TYPO3

Craft CMS

Officieel security-team

28 leden (+ 4 provisional)

Core wel, plugins niet

Ja, kleiner

Ja, professioneel

Ja, commercieel

PSA-systeem vóór patch

Ja

Nee

Nee

Nee

Nee

Release-cadans

Woensdag (vast)

Ad-hoc

Ad-hoc

Gepland per versie

Ad-hoc

Coordinated disclosure

Ja (security.drupal.org)

Beperkt

Ja

Ja

Ja

Contrib-module review

"Opt-in security coverage"

Geen systematische review

Ja

Ja

Plugin store review

Auto-escaping templates

Ja (Twig)

Nee (PHP echo)

Deels

Ja (Fluid)

Ja (Twig)

EOL-beleid

Transparant, jaren vooruit

Vaak stille ondersteuning

Gedocumenteerd

Strikt LTS-schema

Gedocumenteerd



 

 



### Breder capaciteits-vergelijk

Capaciteit

Drupal

WordPress

Contentful

TYPO3

Open source

Ja

Ja

Nee (SaaS)

Ja

Structured content-model

Sterk (Entity API)

Zwak (posts + meta)

Sterk

Sterk

Native multilingual

Sterk

Via plugin

Sterk

Sterk

Granulaire permissions

Sterk

Zwak

Matig

Sterk

Config-as-code

Sterk (YAML sync)

Zwak

Via API

Matig

Views/listings zonder code

Sterk

Zwak

N.v.t. (API-only)

Matig

Accessibility core-focus

Sterk

Matig

N.v.t.

Matig

Headless/API-first

Sterk (JSON:API core)

Matig (REST API)

Headless by design

Matig

Hostingkosten

Zelf kiezen

Zelf kiezen

SaaS, vast

Zelf kiezen

Leercurve

Steil

Zacht

Matig

Steil



 

 



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.



 

 



 

 

 

## Wat Drupal NIET voor je oplost

 

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.



 

 



 

 

 

## Jouw 7-puntige security-checklist

 

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.



 

 



 

 

 

## 5 rode vlaggen dat je setup nu kwetsbaar is

 

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.



 

 



 

 

 

## Wat nu?

 

→ Ik heb een oude Drupal-site en maak me zorgen.  
Start met een [Drupal-audit](/dienst/drupal-audit). Je krijgt een gestructureerd rapport met bevindingen en prioritering.

→ Ik bouw een nieuwe website.  
Begin met [Drupal-development.](/dienst/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 &amp; support ](/dienst/drupal-onderhoud-support)— inclusief [hosting](/dienst/drupal-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](/dienst/drupal-migratie) — verder uitstellen maakt het risico alleen groter.



 

 



 

 

 

## Leuke feiten over Drupal-security

 

- 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.



 

 



 

 

 

 

 

 





## Lees meer

 

  [ ![Drupal vs WordPress: welk CMS past beter bij jouw website?](/sites/default/files/2026-04/Drupal%20en%20WordPress%20in%20balans.png) Drupal 

 

### Drupal vs WordPress: welk CMS past beter bij jouw website?

Drupal en WordPress het zijn beide CMS (Content Management Systemen), maar wat zijn de verschillen en overeenkomsten tussen beide CMS’en. In dit artikel duik ik daar verder op in en geef ik overzichtelijk weer wat zowel de voordelen als nadelen zijn van beide CMS’en.

  Lees meer     

 ](https://vdmi.nl/blog/drupal-vs-wordpress-welk-cms-past-beter-bij-jouw-website)  [ ![Van SharePoint naar Drupal: minder vendor lock-in, meer grip op content en data](/sites/default/files/2026-04/ChatGPT%20Image%201%20apr%202026%2C%2013_23_56.png) Drupal 

 

### Van SharePoint naar Drupal: minder vendor lock-in, meer grip op content en data

Steeds meer overheidsorganisaties heroverwegen SharePoint, niet omdat het niet werkt, maar omdat afhankelijkheid van een klein aantal grote leveranciers bestuurlijk en technisch steeds gevoeliger wordt. Voor organisaties die meer grip willen op content, data en exit-strategie, komt een open platform als Drupal dan serieus in beeld.

  Lees meer     

 ](https://vdmi.nl/blog/sharepoint-drupal-minder-vendor-lock-meer-grip-content-en-data)  [ ![Slimmere websites met de nieuwe Drupal AI 1.2](/sites/default/files/2026-03/ai_generated.jpg) A.I. Drupal 

 

### Slimmere websites met de nieuwe Drupal AI 1.2

Stel je voor: je hebt een website waar je regelmatig teksten plaatst, foto’s toevoegt of nieuwsberichten maakt. Normaal moet je alles zelf verzinnen, schrijven en netjes opmaken. Dat kost tijd.

  Lees meer     

 ](https://vdmi.nl/blog/slimmere-websites-nieuwe-drupal-ai-12) 







 



## Kom een bakkie met ons doen

 

Neem gerust contact met ons op, want wij voorzien je graag van een passend advies. Wij informeren je graag over de mogelijkheden die Drupal je biedt en maken bovendien alles op maat voor jouw bedrijf of organisatie.

 [ Neem contact op     ](/contact) 

 

 

 

## Veelgestelde vragen

    Is Drupal veiliger dan WordPress?         Voor enterprise-setups: ja, structureel. Drupal heeft een publiek Security Team, voorspelbare releases, een PSA-mechanisme en Twig auto-escaping in core. Het grootste WordPress-risico ligt niet in de kern, maar in de honderden plugins per site — waar geen gecoördineerd review- of disclosure-proces op zit.

 

 



   Waar blinkt Drupal in uit vergeleken met andere CMS'en?         In zeven punten: officieel security-team, granulaire permissions, gestructureerde content-modellen, native meertaligheid, configuration-as-code, accessibility in de kern en Views zonder code. Zie de sectie hierboven voor scenario's.

 

 



   Hoe snel moet ik een security-update installeren?         Vuistregel: reguliere security-releases binnen 72 uur, kritieke (PSA-aangekondigde) releases binnen 24 uur. Bij Drupalgeddon was het venster 7 uur. Plan je patch-woensdag in de sprint.

 

 



   Wat is een PSA en moet ik erop reageren?         Een Public Service Announcement is een vooraankondiging (meestal 2-3 dagen) voor een kritieke security-release. Het geeft geen details, wel urgentie. Reageren is simpel: zet je ops-team stand-by voor de woensdag erna.

 

 



   Kan ik Drupal 7 nog veilig draaien?         Nee, niet structureel. Drupal 7 is sinds januari 2025 end-of-life; geen officiële security-patches meer vanuit drupal.org. Er zijn commerciële extended-support-aanbieders, maar dat is een tussenoplossing, geen eindbestemming. Plan een migratie naar Drupal 11.

 

 



   Wat kost security-onderhoud per jaar?         Voor een middelgrote Drupal-site (circa 50-500 pagina's, 10-30 contrib-modules, één productieomgeving plus staging) ligt een realistische bandbreedte voor app-level security-beheer zónder hosting rond €2.700-€4.800 per jaar (excl. btw). Inclusief managed Drupal-hosting met monitoring, backups en SLA kom je eerder op €4.300-€9.300 per jaar (excl. btw). Dat is een benchmark samengesteld uit publieke prijslijsten van Nederlandse Drupal-specialisten en managed-hosting-aanbieders — geen concrete offerte. Voor additionele uren (incident-respons, maatwerk) zie je in de markt tarieven rond €75-€115 per uur (bron: Sitegurus, Simplicate Agencies Benchmark Q3 2025 via Emerce). De kosten van níet-onderhouden zijn bijna altijd hoger: een incident-respons na compromittering kost vaak een veelvoud van een jaarcontract.

 

 



   Heb ik een specialist nodig of kan ik het zelf?         Dat hangt af van je omgeving. Één eenvoudige site met een ervaren developer: zelf redelijk te doen. Meerdere sites, compliance-eisen (ISO 27001, Besluit Toegankelijkheid) of 24/7-uptime: neem een specialist. Een goede Drupal-specialist verdient zichzelf terug in voorkomen incidenten.

 

 [ Drupal-specialist ](/dienst/drupal-audit) 



   Is hosting ook onderdeel van security?         Ja — hosting is de helft van het verhaal. OS-patches, firewall-regels, TLS-configuratie, backup-retentie en toegangsbeheer vallen buiten Drupal. Overweeg managed Drupal-hosting waar deze lagen geïntegreerd zijn met het CMS-onderhoud.

 

 [ managed Drupal-hosting ](/dienst/drupal-hosting)