De recente beveiligingsproblemen met PHP, waardoor op 21 oktober 2026 verschillende websites preventief offline werden gehaald, hebben mij opnieuw aan het denken gezet over een beslissing die ik ongeveer twintig jaar geleden al heb genomen.
Ik gebruik PHP al jarenlang niet meer voor mijn eigen softwareprojecten. En daar heb ik goede redenen voor.
Dat betekent niet dat ik nooit met PHP in aanraking ben gekomen. Integendeel. Op mijn servers heeft PHP gestaan, ik heb verschillende WordPress-websites beheerd en ik heb klanten geholpen met bestaande PHP-websites en webwinkels. Ik heb ook regelmatig projecten begeleid waarbij klanten van WordPress of een klassiek PHP-systeem naar een andere technologie wilden overstappen.
Maar voor de software die ik zelf ontwikkel, kies ik al jarenlang hoofdzakelijk voor Python, Django en gerelateerde technologieën.
Waarom? Niet omdat Python volledig veilig zou zijn. Dat bestaat niet. Maar vanwege mijn ervaringen met stabiliteit, onderhoudbaarheid, beveiliging en de manier waarop software op lange termijn beheerd kan worden.
1. Twintig jaar ervaring met de klassieke PHP-configuratie
Toen ik ongeveer twintig jaar geleden met websites en servers begon te werken, was de combinatie Apache, PHP en MySQL bijzonder populair.
Die combinatie, vaak LAMP genoemd wanneer Linux als besturingssysteem wordt gebruikt, was relatief eenvoudig te installeren. De software was gratis, hosting was goedkoop en vrijwel iedere provider ondersteunde PHP.
Voor kleine websites was dat aantrekkelijk. Maar in de praktijk begon ik steeds vaker de nadelen te zien.
Ik kwam websites tegen die moeilijk te onderhouden waren, verouderde plug-ins gebruikten, onveilig waren geconfigureerd of volledig afhankelijk waren van ontwikkelaars die inmiddels niet meer bereikbaar waren.
Vooral bij WordPress-websites zag ik hoe een ogenschijnlijk eenvoudige installatie na verloop van tijd kon veranderen in een verzameling thema's, plug-ins, updates en afhankelijkheden.
En wanneer ergens iets misging, moest je vaak eerst uitzoeken welke component verantwoordelijk was.
Mijn frustratie was niet één specifieke fout in PHP, maar de opeenstapeling van problemen die ik binnen dit ecosysteem tegenkwam.
Toen ik uiteindelijk volledig overstapte op Python en verwante technologieën, voelde dat als een enorme verbetering.
2. Een website kan van de ene dag op de andere verdwijnen
Een van de meest frustrerende situaties die ik in de praktijk ben tegengekomen, is wanneer een website jarenlang lijkt te functioneren en vervolgens plotseling ernstige problemen krijgt.
Je wordt 's morgens wakker en ontdekt dat een website niet meer bereikbaar is, bestanden zijn verdwenen of een database mogelijk is buitgemaakt.
Vervolgens begint het onderzoek.
- Welke beveiligingsupdates zijn niet uitgevoerd?
- Welke plug-in of component was kwetsbaar?
- Wie had toegang tot de server?
- Zijn er back-ups beschikbaar?
- Zijn er persoonsgegevens gestolen?
- Moeten klanten en bevoegde instanties worden geïnformeerd?
- Wie gaat de website herstellen, en hoeveel zal dat kosten?
Ik heb in mijn carrière dergelijke problemen en de gevolgen ervan bij websites en klanten meegemaakt. Soms bleek een configuratie al jarenlang verouderd. Soms was het project afhankelijk van iemand die niet meer beschikbaar was.
Uiteraard kunnen zulke incidenten ook bij Python, Java of .NET voorkomen. Niet elke verdwenen website is bovendien het gevolg van een beveiligingslek: fouten bij updates, beheerproblemen en ontbrekende back-ups kunnen vergelijkbare schade veroorzaken.
Maar juist daarom is mijn keuze voor een softwarearchitectuur die ik zelf goed kan onderhouden en controleren zo belangrijk geworden.
3. Waarom ik uiteindelijk voor Python heb gekozen
Python heeft mijn manier van software ontwikkelen fundamenteel veranderd.
Wat mij vooral overtuigde, was de leesbaarheid van de code, de consistente structuur en de mogelijkheid om complexe applicaties relatief overzichtelijk te houden.
Met Django beschik je bovendien over een framework dat veel belangrijke onderdelen van een webapplicatie al structureel organiseert.
- Een ORM voor databasecommunicatie.
- Ingebouwde authenticatie en gebruikersbeheer.
- Bescherming tegen veelvoorkomende webaanvallen.
- Een duidelijk model voor URL-routing en views.
- Database-migraties en gestructureerd applicatiebeheer.
- Uitgebreide mogelijkheden voor testen en automatisering.
Ik gebruik onder andere Python, Django, Apache met mod_wsgi en PostgreSQL.
Die combinatie is niet de enige goede keuze. Ook andere stacks kunnen uitstekend functioneren. Maar voor de projecten die ik ontwikkel, geeft deze architectuur mij veel controle over de code, de infrastructuur en het onderhoud.
Voor mij is Python niet alleen een programmeertaal. Het is een technologie die de ontwikkeling van complexe software aanzienlijk toegankelijker heeft gemaakt.
De mensen die Python hebben ontwikkeld en verder uitgebouwd, hebben naar mijn mening een bijzonder grote bijdrage geleverd aan de vooruitgang van softwareontwikkeling.
4. Grote platforms bewijzen dat Python ook op schaal werkt
Soms wordt Python voorgesteld als een taal voor eenvoudige scripts, automatisering of wetenschappelijk onderzoek.
Maar Python wordt ook gebruikt in grootschalige internetplatforms.
Instagram is een bekend voorbeeld van een platform dat historisch sterk op Python en Django heeft gebouwd. Pinterest heeft eveneens Python en Django gebruikt binnen zijn technische infrastructuur.
Dat betekent niet dat zulke bedrijven uitsluitend Python gebruiken. Grote platforms combineren meestal verschillende programmeertalen, databases, caches en gespecialiseerde diensten.
Maar het laat wel zien dat Python niet alleen geschikt is voor kleine websites.
Goede architectuur, schaalbaarheid en onderhoudbaarheid zijn belangrijker dan de eenvoudige vraag welke programmeertaal het snelst is.
5. Zijn PHP en .NET dan fundamenteel onveilig?
Nee. Dat zou een te eenvoudige conclusie zijn.
PHP en Microsoft .NET worden wereldwijd gebruikt, ook binnen grote organisaties en overheidsinstellingen. Ook Python, Java en andere technologieën hebben kwetsbaarheden gekend.
Bij de overheid bestaan bovendien veel verschillende technologische omgevingen. Het zou onjuist zijn om te stellen dat vrijwel alle overheidssystemen uitsluitend op PHP of .NET draaien.
Mijn persoonlijke voorkeur voor Python betekent dus niet dat iedere PHP-website slecht gebouwd is of dat .NET onbetrouwbaar zou zijn.
Integendeel: ik beschouw .NET als een volwassen en technisch sterke omgeving.
Het probleem is dat iedere technologie afhankelijk is van de kwaliteit van haar implementatie, het onderhoud en de beveiliging van de volledige infrastructuur.
Maar het recente PHP-incident toont wel aan dat een probleem diep in een programmeertaal of runtime gevolgen kan hebben voor een enorm aantal websites tegelijkertijd.
6. De echte kwetsbaarheid: geheugenbeheer in C en C++
Het interessante aan de ontdekte PHP-beveiligingslekken is dat ze betrekking hebben op de interne werking van de programmeertaal.
PHP is grotendeels geïmplementeerd in C, een programmeertaal die ontwikkelaars rechtstreeks met het geheugen laat werken.
Bij het beheren van geheugen kunnen programmeerfouten ontstaan.
Use-after-free
Een programma geeft een geheugenblok vrij, maar probeert het daarna toch opnieuw te gebruiken.
Wanneer dat geheugen intussen andere informatie bevat, kan het programma die gegevens verkeerd interpreteren.
Buffer overflow
Een programma schrijft meer gegevens naar een geheugenbuffer dan waarvoor ruimte beschikbaar is.
Daardoor kunnen aangrenzende gegevens worden overschreven.
Remote Code Execution
Wanneer een aanvaller een geheugenfout kan misbruiken om de uitvoering van het programma te beïnvloeden, kan onder bepaalde omstandigheden Remote Code Execution ontstaan.
Dat betekent dat een aanvaller opdrachten op een externe server kan laten uitvoeren.
Een hacker hoeft hiervoor niet noodzakelijk een PHP-bestand te uploaden. Soms kan een speciaal voorbereide HTTP-aanvraag voldoende zijn om een kwetsbaar onderdeel van de PHP-runtime te activeren.
Daarvoor moet de aanvaller uiteraard de specifieke fout kunnen bereiken en daadwerkelijk kunnen uitbuiten. Niet iedere geheugenfout leidt automatisch tot een succesvolle aanval.
7. Maar Python, Java en .NET gebruiken toch ook C of C++?
Precies. En dat is de veel interessantere vraag.
De standaardimplementatie van Python, CPython, is grotendeels in C geschreven. Java gebruikt een runtime met native componenten en ook .NET bevat native code.
Daarom kunnen geheugenproblemen in native onderdelen ook deze technologieën treffen.
| Technologie | Geheugenbeheer | Mogelijke risico's |
|---|---|---|
| C / C++ | Veel directe controle | Buffer overflows, use-after-free en geheugenbeschadiging |
| PHP | Automatisch voor applicatiecode; runtime grotendeels in C | Kwetsbaarheden in de runtime, extensies en applicaties |
| Python | Automatisch | Kwetsbaarheden in CPython, native bibliotheken en applicatiecode |
| Java | Garbage collection | Kwetsbaarheden in de JVM, native bibliotheken en applicaties |
| C# / .NET | Automatisch beheerd geheugen | Kwetsbaarheden in de runtime, native componenten en applicaties |
| Rust | Geheugenveiligheid grotendeels tijdens compilatie afgedwongen | Andere softwarefouten en risico's in unsafe-code |
Het grote voordeel van Python, Java en C# is dat gewone applicatiecode veel minder direct verantwoordelijk is voor handmatig geheugenbeheer.
Dat vermindert een belangrijke categorie programmeerfouten. Maar het maakt de onderliggende runtime niet automatisch onkwetsbaar.
Daarom kan men niet concluderen dat alle technologieën even onveilig zijn, maar evenmin dat één taal volledige veiligheid garandeert.
8. AI verandert de wereld van softwarebeveiliging
Volgens professor Vincent Ginis van de Vrije Universiteit Brussel is het recente PHP-incident een waarschuwing voor een veel grotere ontwikkeling.
Artificiële intelligentie maakt het mogelijk om steeds sneller fouten te ontdekken in software die al jarenlang bestaat.
Vroeger moest een gespecialiseerde beveiligingsonderzoeker soms maanden besteden aan het analyseren van complexe broncode, geheugenstructuren en mogelijke aanvalsmethoden.
Vandaag kunnen AI-systemen helpen om grote hoeveelheden code te analyseren, verdachte patronen te vinden en mogelijke kwetsbaarheden te onderzoeken.
Dat is een enorme vooruitgang voor softwarebeveiliging, maar het heeft ook een gevaarlijke keerzijde.
Dezelfde hulpmiddelen die ontwikkelaars helpen beveiligingslekken te ontdekken, kunnen ook kwaadwillenden helpen kwetsbaarheden te vinden.
De technische kennis die vroeger slechts voor een beperkte groep specialisten toegankelijk was, wordt daarmee breder beschikbaar.
9. Kan AI straks kwetsbaarheden ontdekken in vrijwel alle software?
In theorie kan AI helpen bij het onderzoeken van vrijwel elke grote softwarecodebase waarvan voldoende informatie beschikbaar is.
Dat betekent niet dat AI automatisch iedere server kan hacken.
Een succesvolle aanval vereist meer dan alleen het vinden van een programmeerfout.
- De kwetsbare code moet bereikbaar zijn.
- Een aanvaller moet de fout kunnen activeren.
- De fout moet exploiteerbaar zijn.
- Eventuele beveiligingsmaatregelen moeten worden omzeild.
- De aanvaller moet voldoende toegangsrechten verkrijgen om schade aan te richten.
Toch kunnen steeds krachtigere AI-systemen het aantal ontdekte kwetsbaarheden fors verhogen.
Dat verandert de situatie voor softwareontwikkelaars, hostingproviders, bedrijven en overheden.
Het grootste gevaar is misschien niet dat software plotseling slechter wordt, maar dat we sneller ontdekken hoeveel verborgen problemen al jarenlang aanwezig waren.
10. Waarom oudere software steeds problematischer wordt
Veel organisaties gebruiken software die jaren of zelfs tientallen jaren geleden is ontwikkeld.
Die software functioneert soms prima en wordt daarom nauwelijks aangepast.
Maar onder de oppervlakte kunnen nog altijd beveiligingsfouten bestaan die destijds niet ontdekt werden.
AI maakt het mogelijk om juist die oude code opnieuw en systematischer te onderzoeken.
Dat kan grote gevolgen hebben voor organisaties die afhankelijk zijn van verouderde applicaties, oudere runtimes, niet-onderhouden plug-ins en complexe infrastructuur.
In de praktijk is het daarom niet voldoende om uitsluitend naar de programmeertaal te kijken.
Ook de gebruikte versies, bibliotheken, rechtenstructuur, configuratie, back-ups en procedures voor beveiligingsupdates zijn van groot belang.
11. Wat betekent dit voor bedrijven en softwareontwikkelaars?
Mijn belangrijkste aanbeveling is om software niet uitsluitend te beoordelen op aanschafprijs, populariteit of de hoeveelheid beschikbare plug-ins.
De onderhoudbaarheid op lange termijn is minstens zo belangrijk.
- Gebruik ondersteunde softwareversies. Verouderde technologie zonder beveiligingsupdates vormt een onnodig risico.
- Beperk afhankelijkheden. Iedere extra plug-in of bibliotheek betekent bijkomend onderhoud en mogelijk een groter aanvalsoppervlak.
- Beperk serverrechten. Een gehackte webapplicatie mag niet automatisch toegang geven tot de volledige infrastructuur.
- Maak onafhankelijke back-ups. Controleer regelmatig of deze daadwerkelijk kunnen worden teruggezet.
- Monitor systemen. Een beveiligingsincident wordt niet altijd onmiddellijk zichtbaar.
- Investeer in onderhoudbare architectuur. Een systeem dat eenvoudig te begrijpen en te actualiseren is, heeft op lange termijn grote voordelen.
12. Mijn conclusie: ik blijf bij Python
Het recente PHP-incident bevestigt voor mij opnieuw hoe belangrijk de keuze van een technische architectuur is.
Ik hoop uiteraard dat de ontdekte kwetsbaarheden met de beschikbare beveiligingsupdates effectief worden afgesloten en dat websites snel weer veilig kunnen functioneren.
Maar zelfs als deze problemen volledig worden opgelost, verandert dat mijn persoonlijke keuze niet.
Ik heb in de afgelopen twintig jaar te veel problemen meegemaakt met verouderde PHP-installaties, complexe WordPress-configuraties, slecht onderhouden websites en moeilijk te herstellen systemen.
Daarom ben ik jaren geleden overgestapt op Python en verwante technologieën.
Niet omdat die technologieën nooit kwetsbaarheden zullen hebben. Ook die software vereist voortdurend onderhoud en beveiligingsupdates.
Maar omdat ik vanuit mijn eigen ervaring veel meer vertrouwen heb in de manier waarop ik daarmee complexe systemen kan ontwikkelen, begrijpen en beheren.
Mijn persoonlijke keuze blijft Python. Niet vanwege een belofte van absolute veiligheid, maar vanwege de combinatie van structuur, leesbaarheid, onderhoudbaarheid en ontwikkelproductiviteit.
En misschien is de belangrijkste conclusie van het hele verhaal wel deze:
AI maakt onze software niet noodzakelijk onveiliger. AI laat ons vooral steeds sneller ontdekken hoe onveilig sommige onderdelen van onze bestaande software al die tijd zijn geweest.
De komende jaren zal de uitdaging daarom niet alleen bestaan uit het ontwikkelen van nieuwe software, maar vooral uit het veilig houden van de enorme hoeveelheid bestaande software waarop onze economie en samenleving draaien.
Reacties
Een reactie posten