Veel beveiligingslekken ontstaan niet door slechte bedoelingen, maar door tijdsdruk, menselijke fouten of een gebrek aan beveiligingskennis binnen het ontwikkelproces. Ontwikkelaars werken onder hoge druk, deadlines zijn strak en nieuwe features krijgen vaak voorrang op beveiliging. Dit kan ertoe leiden dat een kwetsbaarheid zoals het toekennen van onjuiste rollen/rechten gemakkelijk over het hoofd wordt gezien. Denk aan een situatie waarin een developer “even snel” een admin-rol toevoegt zodat een tester iets kan verifiëren, maar daarna vergeet deze weer te verwijderen. Of een sprint waarin een nieuwe module wordt opgeleverd, maar waarin de toegangsrestricties pas later worden toegevoegd omdat het ''nu even niet uitkomt”. Pas later wanneer zo een kwetsbaarheid wordt misbruikt, blijkt hoe groot de impact van zo een fout kan zijn. Onbevoegde gebruikers krijgen ineens toegang tot gevoelige gegevens of functionaliteiten die nooit voor hen bedoeld waren.
Gelukkig is er een wereldwijde community die zich al meer dan twintig jaar inzet om die fouten te begrijpen en te voorkomen, namelijk de Open Web Application Security Project (OWASP). Achter de OWASP schuilt een netwerk van (security) specialisten en ontwikkelaars met één gezamenlijke missie: software veilig maken. Dit doen ze door middel van open-source tools, conferenties en controlelijsten die ontwikkelaars kunnen raadplegen bij het ontwikkelproces.
Een van de bekendste initiatieven van OWASP is de OWASP Top 10, een bewustwordingsdocument voor ontwikkelaars en webapplicatiebeveiliging, die de tien meest voorkomende vuilkuilen laat zien. Wat in 2003 begon als een simpel initiatief om ontwikkelaars te helpen veiliger software te bouwen, is inmiddels uitgegroeid tot een maatstaf voor veilige softwareontwikkeling wat gebruikt wordt voor compliance, educatie en leveranciertools. Daarnaast speelt de OWASP Top 10 in de dagelijkse praktijk een belangrijke rol als hulpmiddel om kwetsbaarheden te herkennen binnen deze risicocategorieën, bijvoorbeeld tijdens code-reviews, penetratietests of security audits. Omdat de lijst ongeveer elke vier jaar wordt vernieuwd, leek het mij interessant om te onderzoeken hoe de OWASP Top 10 in de afgelopen acht jaar is veranderd.
Binnen de lijst van 2017 zien wij dat de nadruk vooral ligt op directe kwetsbaarheden in de code van webapplicaties. Dit is dan een lijst die vooral bedoeld is voor ontwikkelaars en ingaat op het voorkomen van inbraak binnen een app door bijvoorbeeld foutieve validatie. De risico’s zijn vooral technisch en concreet, denk aan SQL-injecties, foutieve wachtwoordafhandeling en slechte logging. In de praktijk betekent dit dat organisaties vooral risico lopen op directe datalekken, systeemmisbruik of ongeautoriseerde toegang als deze fouten niet worden aangepakt. Het dwingt teams om secure coding-richtlijnen te volgen en zorgt ervoor dat organisaties investeren in code reviews, pentesten en ontwikkeltrainingen om deze klassieke fouten te voorkomen.
Bron: OWASP Foundation (2021)
De versie van 2021 laat een belangrijke verschuiving zien, de grootste risico’s zitten niet meer alleen in fouten in de code, maar juist in hoe systemen vanaf het begin worden ontworpen en ingericht. Zo zien we dat Broken Access Control (gebrekkige toegangscontrole) op nummer één komt: mislukte autorisatie blijkt het grootste structurele risico. Broken Access Control ontstaat wanneer een systeem niet goed afdwingt wat een gebruiker mag doen of zien. Het gevolg hiervan is dat onbevoegden toegang hebben tot gegevens, instellingen of functies en daardoor buiten hun rechten kunnen handelen. Verder is binnen de lijst te zien dat de positie van elk risico is veranderd en dat er bovendien drie nieuwe risico’s zijn toegevoegd:
Deze nieuwe risico’s introduceren het idee dat beveiliging vanaf het ontwerp moet beginnen. In de praktijk betekent dit dat organisaties niet alleen naar technische fouten moeten kijken, maar ook naar hun ontwikkelprocessen, architectuurkeuzes en afhankelijkheden in hun softwareketen. Veel kwetsbaarheden ontstaan namelijk doordat processen niet goed zijn ingericht, bijvoorbeeld omdat te veel medewerkers onnodig toegang hebben, updates niet goed gecontroleerd worden of systemen zonder duidelijke beveiliging aan elkaar gekoppeld zijn. Wanneer dit in de basis niet goed geregeld is, kunnen problemen zich door het hele systeem verspreiden. Zonder een veilige basis in het ontwerp lopen organisaties een grotere kans op structurele kwetsbaarheden die later moeilijker en kostbaarder te herstellen zijn.

Bron: OWASP Foundation (2025)
In de nieuwe lijst die begin november dit jaar is gepubliceerd, blijkt dat Broken Access Control nog steeds het grootste en meest voorkomende probleem vormt. Dit toont dat, onlangs technologische vooruitgang, dit een structureel probleem blijft. Het benadrukt het belang dat toegangsbeheer niet als technische bijzaak moet worden gezien, maar als een fundamenteel onderdeel van softwareontwerp. Goed ingerichte toegangscontrole bepaalt immers wie welke gegevens mag zien of wijzigen en vormt daarmee de kern van vertrouwelijkheid en integriteit binnen een systeem.
Een opvallende nieuwkomer in de lijst is Software Supply Chain Failures (fouten in de softwaretoeleveringsketen). Deze categorie maakt duidelijk dat organisaties zich steeds bewuster moeten worden van de risico’s in hun softwareketen. Kwetsbaarheden kunnen niet alleen in eigen code ontstaan, maar ook in gebruikte software, tools en externe componenten. Organisaties leunen steeds meer op externe leveranciers, open-source-componenten en geautomatiseerde bouwsystemen. Als één van die schakels onveilig is, kan dat gevolgen hebben voor iedereen die ervan afhankelijk is.
Een andere nieuwkomer binnen de lijst is Mishandling of Exceptional Conditions (onjuist afhandelen van uitzonderlijke omstandigheden), wat zich richt op foutafhandeling en stabiliteit. Deze categorie toont het belang om vooraf na te denken over wat er mis kan gaan en niet pas reageren als het fout gaat. Verwacht dat er fouten gebeuren en ontwerp je systeem zo dat het daar veilig en gecontroleerd mee omgaat.
De NIS2-richtlijn benadrukt datzelfde principe: systemen moeten bestand zijn tegen verstoringen. Niet alleen door incidenten te voorkomen, maar vooral door ervoor te zorgen dat fouten gecontroleerd worden opgevangen en de continuïteit van diensten gewaarborgd blijft.
Om de OWASP-uitgangspunten goed te borgen, is een structurele aanpak van kwetsbaarheidsmanagement essentieel. Begin met het opstellen van een secure software development lifecycle (SSDLC), waarin de OWASP-richtlijnen in elke ontwikkelfase zijn opgenomen. Zorg vervolgens voor een continu verbeterproces met geautomatiseerde tests op basis van de OWASP Top 10, zodat nieuwe kwetsbaarheden snel worden opgespoord. Tot slot blijft het uitvoeren van een security audit of penetratietest conform OWASP een belangrijke stap om risico’s objectief in kaart te brengen en om te verifiëren dat de beveiliging daadwerkelijk op orde is.
De evolutie van de OWASP Top 10 laat zien dat beveiliging steeds minder over code gaat, en steeds meer over bewustzijn, samenwerking en verantwoordelijkheid in de hele keten. Waar vroeger vooral werd gekeken naar fouten in de techniek, zoals kwetsbare code of zwakke wachtwoorden, ligt de nadruk nu op hoe organisaties omgaan met risico’s in hun hele digitale ecosysteem. Beveiliging is niet langer alleen een taak van ontwikkelaars, maar een gezamenlijke verantwoordelijkheid van leveranciers, bestuurders en gebruikers.
Wil je weten hoe jouw organisatie OWASP principes effectief kan implementeren of hoe je jouw ketenbeveiliging naar een hoger niveau tilt? Neem dan gerust contact met ons op. Wij helpen je graag verder!
Meld je nu aan voor één van de nieuwsbrieven van ICTRecht en blijf op de hoogte van onderwerpen zoals AI, contracteren, informatiebeveiliging, e-commerce, privacy, zorg & ICT en overheid.