Waarom de gebeurtenissen van 21 oktober ons opnieuw laten nadenken over de technologie achter websites. En waarom een andere architectuur soms belangrijker is dan een andere programmeertaal.
Op 21 oktober gingen verschillende websites van Nederlandse overheidsinstanties uit voorzorg offline. Onder andere DigiD, MijnOverheid en Overheid.nl waren tijdelijk niet bereikbaar.
De aanleiding? Twee kritieke beveiligingslekken in PHP, de programmeertaal waarop een groot deel van het internet draait.
De kwetsbaarheden, met een ernstscore van 9,2 op 10, konden onder bepaalde omstandigheden worden misbruikt om op afstand code uit te voeren op een server. In het ergste geval kan een aanvaller daarmee toegang krijgen tot systemen of gevoelige gegevens.
De PHP-ontwikkelaars brachten dezelfde dag beveiligingsupdates uit.
Dat is behoorlijk schrikken. Zeker wanneer je bedenkt hoeveel websites, webshops, bedrijfsapplicaties en overheidsdiensten afhankelijk zijn van PHP.
En natuurlijk komt dan al snel WordPress ter sprake. Niet zo vreemd, want WordPress draait op PHP en is wereldwijd een van de meest gebruikte contentmanagementsystemen.
Toch vind ik het te gemakkelijk om nu naar WordPress te wijzen.
Dit was geen beveiligingslek in WordPress. Het probleem zat een niveau dieper, in de programmeertaal waarop WordPress en veel andere applicaties draaien.
En misschien is dat wel de belangrijkste les van gisteren.
Wij hadden er geen last van. Maar dat maakt ons niet onkwetsbaar.
Met VibeSite hebben we een aantal jaren geleden bewust gekozen voor een andere technische architectuur.
We gebruiken moderne JavaScript- en TypeScript-technologie, waaronder React voor onze frontend. Technologieën die ook bij veel grote internationale bedrijven worden toegepast.
Onze eigen VibeSite-websites draaien niet op PHP. Daardoor waren ze ook niet kwetsbaar voor de specifieke PHP-beveiligingslekken die gisteren bekend werden.
Dat klinkt misschien als een mooi verkoopargument.
Maar ik wil daar wel iets bij zeggen.
Kan ons zoiets dan niet overkomen? Natuurlijk wel.
Iedere programmeertaal, ieder framework en iedere externe afhankelijkheid kan kwetsbaarheden bevatten. Ook React, Node.js en de andere technologieën die wij gebruiken.
Ik zou zelfs niet durven beweren dat onze technologie per definitie veiliger is dan PHP. Daarvoor zijn er te veel factoren die een rol spelen.
Waar ik wel van overtuigd ben, is dat de manier waarop je een website opbouwt een groot verschil kan maken.
Bij VibeSite proberen we het aantal onderdelen dat direct bereikbaar is vanaf het internet zo klein mogelijk te houden.
We gebruiken waar mogelijk vooraf gegenereerde webpagina's. Daardoor hoeft een bezoeker niet bij iedere paginabezoek een CMS, database en allerlei plugins aan te spreken.
Daarnaast scheiden we de publieke website van de omgeving waarin content wordt beheerd.
Dat heeft een aantal voordelen:
- Minder publiek bereikbare onderdelen. Een statische pagina heeft geen actieve CMS-server nodig om de inhoud te tonen.
- Minder afhankelijkheden tijdens een paginabezoek. De website hoeft niet telkens verschillende backend-systemen aan te spreken.
- Meer controle over externe software. We proberen bewust om te gaan met packages en functionaliteit niet onnodig afhankelijk te maken van extra componenten.
- Gescheiden systemen. Problemen in de beheeromgeving hoeven niet automatisch gevolgen te hebben voor de publieke website.
- Gecontroleerde publicaties. Door pagina's vooraf op te bouwen, kunnen we de gepubliceerde website loskoppelen van het proces waarmee content wordt aangepast.
Dat betekent niet dat er geen risico's meer zijn.
Een kwetsbaarheid in ons buildproces, een externe package, een API of onze hostingomgeving kan nog steeds grote gevolgen hebben.
Ook een statische website kan worden aangevallen, bijvoorbeeld via een gecompromitteerd publicatieproces of een kwetsbare externe dienst.
Maar door de verschillende onderdelen bewust van elkaar te scheiden, kunnen we het aanvalsoppervlak beperken.
En misschien nog wel belangrijker: we kunnen de gevolgen van een probleem beter beheersbaar maken.
Veiligheid zit niet alleen in de technologie die je kiest, maar vooral in de manier waarop je die technologie gebruikt.
Een paar regels code die een enorm software-ecosysteem raakten
We hebben eerder gezien hoe kwetsbaar de afhankelijkheden binnen software kunnen zijn.
In 2016 ontstond er een opvallend incident rondom een piepklein JavaScript-package genaamd left-pad.
Het pakketje bestond uit slechts elf regels code en deed eigenlijk maar één eenvoudig ding: tekst aan de linkerkant aanvullen tot een bepaalde lengte.
Toch waren ontzettend veel andere softwarepakketten ervan afhankelijk.
Toen de ontwikkelaar het pakket na een conflict van npm verwijderde, ontstonden wereldwijd problemen met het bouwen van software.
Een minuscuul stukje code bleek een onverwacht belangrijk onderdeel van een enorm software-ecosysteem.
Twee jaar later, in 2018, gebeurde er iets dat vanuit beveiligingsperspectief nog zorgwekkender was.
Een ontwikkelaar droeg het beheer van het populaire JavaScript-package event-stream over aan een nieuwe beheerder.
Die voegde vervolgens een kwaadaardige afhankelijkheid toe. De schadelijke code was specifiek gericht op gebruikers van een bepaalde cryptowallet.
Dit keer ging het dus niet om een pakket dat verdween, maar om een vertrouwde afhankelijkheid die werd misbruikt.
Twee verschillende incidenten, maar met dezelfde onderliggende les.
We bouwen steeds meer software op onderdelen die door anderen worden ontwikkeld en onderhouden. En we vertrouwen erop dat die onderdelen veilig en beschikbaar blijven.
Dat geldt voor PHP en WordPress, maar net zo goed voor JavaScript, React en vrijwel iedere andere moderne ontwikkelomgeving.
Het is dus niet zo dat de ene wereld veilig is en de andere niet.
We moeten ons vooral bewust zijn van die afhankelijkheden en nadenken over wat er gebeurt als er iets misgaat.
Een enorm deel van het internet. Maar wie betaalt eigenlijk voor het onderhoud?
Wat mij bij het nieuws van gisteren misschien nog wel het meest opviel, was de organisatie achter PHP.
PHP is open-source software. Het wordt onderhouden door ontwikkelaars en ondersteund door de PHP Foundation, een non-profitorganisatie.
Daar is op zichzelf niets mis mee. Sterker nog, zonder open-source software zou het internet zoals we dat kennen nauwelijks bestaan.
Maar er zit wel een bijzondere tegenstelling in.
Aan de ene kant hebben we een programmeertaal waarop ontzettend veel commerciële websites, webshops, overheidsdiensten en bedrijfsapplicaties draaien.
Aan de andere kant staat een relatief kleine organisatie die afhankelijk is van sponsoring en bijdragen vanuit de community.
En als je naar de cijfers kijkt, wordt dat contrast behoorlijk duidelijk.
Volgens het Impact and Transparency Report 2025 van de PHP Foundation ontving de organisatie in 2025 in totaal 730.534 dollar aan bijdragen.
De uitgaven bedroegen datzelfde jaar 784.376 dollar.
Eind 2025 ondersteunde de Foundation elf ontwikkelaars, deels fulltime en deels parttime, die werken aan de ontwikkeling, het onderhoud en de beveiliging van PHP.
Elf ontwikkelaars.
Voor een programmeertaal waarop een enorm deel van het internet vertrouwt.
Natuurlijk wordt PHP niet uitsluitend door deze elf mensen ontwikkeld. Er is een bredere community van ontwikkelaars, bedrijven en vrijwilligers die bijdragen aan het project.
Maar toch vind ik die cijfers opvallend.
Kijk bijvoorbeeld naar het commerciële ecosysteem rondom PHP.
WordPress vormt de basis voor een wereldwijde markt van hostingbedrijven, bureaus, pluginontwikkelaars en andere dienstverleners.
Laravel heeft eveneens een indrukwekkend ecosysteem opgebouwd met commerciële producten, hostingdiensten en ontwikkeltools.
Er wordt ontzettend veel geld verdiend dankzij technologie die grotendeels open source beschikbaar wordt gesteld.
En dat is prima.
Maar het roept bij mij wel een vraag op.
Als zoveel bedrijven geld verdienen dankzij PHP, zou er dan niet structureel veel meer geld moeten terugvloeien naar het onderhoud en de beveiliging van de taal zelf?
Het is goed om daarbij te vermelden dat verschillende bedrijven, waaronder partijen uit de WordPress- en Laravel-wereld, de PHP Foundation al financieel ondersteunen.
Het is dus zeker niet zo dat niemand verantwoordelijkheid neemt.
Maar wanneer je de omvang van het commerciële ecosysteem afzet tegen het budget van de Foundation, vraag ik me af of die verhouding nog wel klopt.
Misschien moeten grote bedrijven die profiteren van open-source software dit soort bijdragen veel meer als een vanzelfsprekend onderdeel van hun bedrijfsvoering beschouwen.
Niet als donatie, maar als investering in de infrastructuur waarop hun eigen producten draaien.
Ook het beveiligingsproces verdient aandacht
De PHP Foundation heeft inmiddels zelf uitgebreid gereageerd op de gebeurtenissen.
Daaruit blijkt dat het oplossen van de kwetsbaarheden ingewikkeld was. De problemen zaten diep in het geheugenbeheer en de foutafhandeling van PHP.
Bovendien was een onderliggend probleem al eerder bij het beveiligingsteam bekend, maar bleek de uiteindelijke impact groter dan aanvankelijk werd aangenomen.
De Foundation erkent dat de interne processen op onderdelen beter hadden moeten functioneren en werkt aan verdere verbeteringen.
Dat vind ik een belangrijke constatering.
Niet om de ontwikkelaars iets te verwijten, maar omdat dit precies laat zien waarom structurele financiering zo belangrijk is.
Beveiligingsonderzoek, codebeoordelingen, onderhoud en het zorgvuldig uitbrengen van updates kosten tijd en geld.
En bij technologie waarvan zoveel organisaties afhankelijk zijn, moeten we daar niet te lichtzinnig over denken.
Moeten we dan allemaal stoppen met WordPress?
Nee. Dat lijkt me niet realistisch en in veel gevallen ook helemaal niet nodig.
WordPress heeft een enorme gebruikersgroep opgebouwd. Het is toegankelijk, herkenbaar en biedt bedrijven veel mogelijkheden.
Bovendien zijn er miljoenen ondernemers die helemaal niet bezig willen zijn met de onderliggende technologie.
Zij willen gewoon een website die goed werkt.
En dat begrijp ik.
Tegelijkertijd denk ik wel dat we bij nieuwe projecten kritischer mogen kijken naar de technische keuzes die we maken.
Zeker bij overheidsorganisaties, zorginstellingen en andere partijen waar beschikbaarheid en beveiliging extra belangrijk zijn.
Daar zou ik verwachten dat er nadrukkelijker wordt gekeken naar architecturen waarbij een publiek toegankelijke website niet afhankelijk is van een volledig dynamisch CMS.
Die alternatieven bestaan namelijk al jaren.
Denk aan statisch gegenereerde websites, gescheiden frontends en backend-systemen die niet rechtstreeks toegankelijk zijn voor bezoekers.
Dat betekent overigens niet dat iedere overheidsorganisatie morgen PHP moet vervangen.
Ook migreren brengt risico's met zich mee. En een slecht onderhouden applicatie in een andere programmeertaal is niet automatisch veiliger.
Bovendien is PHP zelf geen verouderde technologie die geen toekomst meer heeft. De taal wordt actief ontwikkeld en moderne PHP-frameworks kunnen uitstekende applicaties opleveren.
Maar bij nieuwe projecten of grote vernieuwingen zou de vraag wat mij betreft vaker moeten zijn:
Welke architectuur past het beste bij de risico's, de levensduur en het belang van deze website?
In plaats van automatisch te kiezen voor wat we al jaren gebruiken.
En toch zijn wij zelf weer met WordPress aan de slag gegaan
Dat klinkt misschien tegenstrijdig.
We hebben met VibeSite jarenlang gebouwd aan ons eigen websiteplatform, juist omdat we meer controle wilden over techniek, performance, content en beveiliging.
En inmiddels bieden we met VibeSite Connect ook ondersteuning voor WordPress-websites.
Waarom?
Omdat er ontzettend veel vraag naar is.
We merken regelmatig dat klanten niet vragen om een nieuwe website, maar heel specifiek om een WordPress-website.
Dat is een belangrijk verschil.
Voor veel organisaties is WordPress een vertrouwde omgeving. Medewerkers kennen het systeem, marketingteams kunnen ermee werken en er is een enorme hoeveelheid kennis beschikbaar.
Die bestaande behoefte kun je negeren.
Maar je kunt ook kijken hoe je WordPress slimmer kunt inzetten.
Dat laatste hebben wij gedaan.
WordPress als CMS, niet als complete website
Met VibeSite Connect kiezen we voor een andere benadering.
WordPress mag blijven doen waar het goed in is: het beheren van content.
Maar waarom zou WordPress ook verantwoordelijk moeten zijn voor het tonen van iedere pagina aan iedere bezoeker?
Wij kunnen WordPress gebruiken als headless CMS.
Dat betekent dat de content gewoon in WordPress wordt beheerd, maar de publieke website met een aparte, moderne frontend wordt opgebouwd.
Die frontend kan vervolgens vooraf worden gegenereerd en als statische website worden gepubliceerd.
Dat levert een aantal interessante voordelen op.
De website hoeft niet bij iedere bezoeker WordPress of de database aan te spreken.
De publieke website kan daardoor snel worden geladen en is minder afhankelijk van de beschikbaarheid van het CMS.
Ook kunnen we het aantal WordPress-plugins beperken.
Want veel functionaliteit waarvoor normaal gesproken extra plugins nodig zijn, kunnen we via VibeSite Connect aanbieden.
Denk aan AI-ondersteuning bij content, het optimaliseren van afbeeldingen, het genereren van alt-teksten, SEO-controles en het analyseren van de kwaliteit van pagina's.
Dat betekent minder extra code binnen WordPress zelf en minder plugins die afzonderlijk moeten worden bijgewerkt en onderhouden.
Natuurlijk geldt ook hier dat minder plugins niet automatisch betekent dat een website veilig is.
Een enkele kwetsbare plugin kan al voldoende zijn om een systeem in gevaar te brengen. En een beveiligingslek in PHP zelf wordt niet opgelost door plugins te verwijderen.
Maar iedere plugin die je niet nodig hebt, is wel een afhankelijkheid minder die kwetsbaar kan worden.
Een veilige website en een beschikbare website zijn niet hetzelfde
Dit is misschien wel het belangrijkste onderscheid dat de gebeurtenissen van gisteren duidelijk maken.
We praten vaak over beveiliging alsof het één onderwerp is.
Maar er is een wezenlijk verschil tussen het voorkomen van een aanval en ervoor zorgen dat een website beschikbaar blijft wanneer er een probleem ontstaat.
Stel dat er opnieuw een ernstig beveiligingslek in PHP wordt ontdekt.
Een lek zoals gisteren, diep in de programmeertaal zelf.
Dat hadden wij met VibeSite Connect niet kunnen voorkomen.
Ook wij kunnen de broncode van PHP niet zomaar repareren.
En als WordPress op een kwetsbare PHP-versie draait, moet die omgeving nog steeds worden bijgewerkt en beveiligd.
Sterker nog: wanneer WordPress publiek bereikbaar blijft, kan een aanvaller mogelijk nog steeds proberen de kwetsbaarheid te misbruiken, ook als bezoekers de website via een aparte frontend bekijken.
Een headless architectuur is dus geen vervanging voor beveiligingsupdates.
Maar er is wel een belangrijk verschil in wat er gebeurt wanneer we WordPress tijdelijk moeten uitschakelen.
WordPress offline. Website gewoon online.
Wanneer de publieke website volledig vooraf is gegenereerd en onafhankelijk wordt gehost, hoeft deze niet offline te gaan wanneer WordPress wordt uitgeschakeld.
De gepubliceerde pagina's staan immers al klaar.
Bezoekers kunnen de bestaande content blijven bekijken, zonder dat er verbinding met WordPress of PHP nodig is.
Dat betekent dat we bij een ernstig beveiligingsprobleem de WordPress-omgeving tijdelijk kunnen afsluiten, terwijl de publieke website beschikbaar blijft.
Uiteraard moeten we daarbij wel rekening houden met dynamische functionaliteit.
Een contactformulier, zoekfunctie, inlogomgeving of webshop kan afhankelijk zijn van aanvullende systemen.
Als die systemen nog gebruikmaken van de kwetsbare WordPress-omgeving, blijven ze een aandachtspunt.
Maar voor veel zakelijke websites kan het belangrijkste gedeelte gewoon blijven functioneren.
En dat is een groot voordeel.
Want wanneer je CMS en publieke website van elkaar hebt gescheiden, kun je een beveiligingsprobleem aanpakken zonder dat je bezoekers daar direct de gevolgen van hoeven te merken.
Het probleem is daarmee niet opgelost.
Maar de impact kan wel aanzienlijk kleiner zijn.
Dat is voor mij de echte kracht van een moderne websitearchitectuur: niet alleen proberen te voorkomen dat er iets misgaat, maar ook zorgen dat niet alles omvalt wanneer het toch gebeurt.
De volgende kwetsbaarheid komt er gegarandeerd
Of het nu PHP is, JavaScript, een cloudplatform of een kleine open-source package: er zullen nieuwe kwetsbaarheden worden ontdekt.
Daar hoeven we onszelf niets over wijs te maken.
En met de toenemende inzet van AI bij het onderzoeken van software verwacht ik dat we de komende jaren nog veel meer kwetsbaarheden gaan ontdekken.
Dat is aan de ene kant positief. Problemen die jarenlang verborgen bleven, kunnen sneller worden gevonden en opgelost.
Maar dezelfde technologie kan ook door kwaadwillenden worden ingezet om kwetsbaarheden sneller op te sporen en te misbruiken.
Het wordt daardoor steeds belangrijker dat organisaties niet alleen nadenken over beveiliging, maar ook over de weerbaarheid van hun systemen.
Hoe snel kunnen we updates uitvoeren?
Welke onderdelen van onze website zijn daadwerkelijk publiek bereikbaar?
Wat gebeurt er als ons CMS tijdelijk moet worden uitgeschakeld?
Kunnen bezoekers de website dan nog steeds gebruiken?
En zijn we afhankelijk van één kwetsbaar onderdeel om alles draaiende te houden?
Dat zijn wat mij betreft belangrijkere vragen dan welke programmeertaal het populairst is.
Niet alles hoeft opnieuw. Maar we kunnen het wel slimmer bouwen.
Het PHP-lek van gisteren is geen reden om massaal afscheid te nemen van WordPress.
Het is wel een goede aanleiding om kritisch naar onze technische keuzes te kijken.
Voor sommige organisaties betekent dat overstappen naar een andere architectuur. Daar kunnen we met VibeSite bij helpen.
Voor andere organisaties is WordPress nog steeds een prima keuze, maar kan de manier waarop het wordt ingezet aanzienlijk worden verbeterd.
Precies daarvoor ontwikkelen we VibeSite Connect.
We hoeven niet alles wat goed werkt weg te gooien.
Maar we hoeven ook niet vast te blijven houden aan een technische opzet omdat we die nu eenmaal al jaren gebruiken.
En misschien moeten we als softwaresector ook wat nadrukkelijker nadenken over de verantwoordelijkheid die we hebben voor de open-source projecten waarop we bouwen.
Want moderne software is niet alleen een kwestie van de juiste frameworks en programmeertalen kiezen.
Het gaat ook over onderhoud, afhankelijkheden, financiering en de vraag hoe goed we voorbereid zijn wanneer er iets misgaat.
De beste website is niet de website die nooit kwetsbaar kan worden. Die bestaat niet.
Het is de website waarbij we vooraf hebben nagedacht over wat er gebeurt als er iets misgaat.
En misschien is dat wel de belangrijkste les van 21 oktober.
Benieuwd hoe wij websites ontwikkelen met een moderne frontend, of hoe je WordPress kunt blijven gebruiken zonder dat je publieke website ervan afhankelijk hoeft te zijn? Bekijk VibeSite en VibeSite Connect.
Bronnen
Schrijft over webdevelopment, AI in het bouwproces en wat er nodig is om een website na livegang goed te houden.
Benieuwd wat dit voor jouw website betekent?
We denken graag mee over wat maatwerk in jouw situatie oplevert.
