Het beveiligen van webapplicaties en de OWASP Top 10 - 2025

Ransomware, phishing, identity theft, botnets, datalekken. Het is dagelijks in het nieuws. Voor softwareontwikkelaars betekent dit één ding: beveiliging moet op orde zijn.

Niet alleen op organisatieniveau, maar ook in je dagelijkse werk. Denk aan je laptop, je infrastructuur en vooral je webapplicaties. Juist daar ontstaan veel kwetsbaarheden.

De vraag is alleen: waar begin je?

Een goed startpunt is de OWASP Top 10. Deze lijst geeft inzicht in de meest voorkomende beveiligingsrisico’s bij webapplicaties en helpt je om gericht maatregelen te nemen.

OWASP Top 10 - 2025

OWASP staat voor Open Worldwide Application Security Project. Dit is een open source initiatief dat zich richt op het verbeteren van softwarebeveiliging. Ze organiseren evenementen, geven trainingen en delen kennis en tools.

Elke vier jaar publiceert OWASP de Top 10 van grootste beveiligingsrisico’s bij het ontwikkelen van webapplicaties. Voor ontwikkelaars is dit een belangrijke leidraad. Het helpt om risico’s te herkennen en te begrijpen welke maatregelen nodig zijn.

Eind 2025 verscheen een nieuwe editie van de OWASP Top 10. Een goed moment om stil te staan bij de huidige stand van zaken: wat zijn op dit moment de grootste beveiligingsrisico’s?

• De nummer 1 van vier jaar geleden staat nog steeds bovenaan: Broken Access Control
• Problemen in de software supply chain zijn sterk toegenomen
• Dit is onder andere terug te zien in de nieuwe nummer 3: Software Supply Chain Failures

Laten we kijken naar de verschillende categorieën in de OWASP Top 10 van 2025.

1. Broken Access Control

Vrijwel elke webapplicatie bevat een vorm van toegangsbeheer. Gebruikers krijgen rechten om bepaalde acties uit te voeren of data te bekijken. Wanneer een gebruiker toegang krijgt tot informatie of functionaliteit zonder dat dit de bedoeling is, spreken we van broken access control.

Deze categorie steeg van plek 5 in 2017 naar plek 1 in 2021 en staat in 2025 nog steeds bovenaan. Dat betekent dat hier weinig vooruitgang in is geboekt. Sterker nog: in de praktijk blijkt dat vrijwel alle geteste applicaties een vorm van dit probleem bevatten.

Het is een brede categorie. Toegangsbeheer kan op verschillende manieren kwetsbaar zijn, bijvoorbeeld:

• URL’s aanpassen om toegang te krijgen tot andere data 
• Rechten manipuleren via tokens of client-side objecten
• Onvoldoende beveiligde API’s
• Fouten in de CORS-configuratie

In 2025 valt ook Server-Side Request Forgery (SSRF) onder deze categorie. Hierbij wordt een server misbruikt om ongewenste requests uit te voeren, bijvoorbeeld naar interne systemen.

Mogelijke oplossingen en tips:

• Beveilig data standaard, tenzij deze expliciet openbaar is
• Gebruik één centraal en herbruikbaar autorisatiesysteem
• Log toegang en signaleer afwijkend gedrag
• Beperk het aantal verzoeken, bijvoorbeeld bij inlogpogingen
• Segmenteer het netwerk

2. Security Misconfiguration

Deze categorie stijgt naar plek 2. Het gaat hier om verkeerde of ontbrekende configuraties, niet om fouten in de programmacode. Door onjuiste instellingen van frameworks, servers of infrastructuur kunnen onveilige situaties ontstaan.

Voorbeelden: 

• Ongebruikte features of services die nog actief zijn
• Standaardaccounts (vaak met standaard wachtwoorden) die niet zijn verwijderd
• Foutmeldingen met te veel technische details, zoals stack traces of codefragmenten

Mogelijke oplossingen en tips:

• Schakel ongebruikte onderdelen uit
• Zorg voor consistente omgevingen (test, acceptatie, productie)
• Gebruik Infrastructure as Code
• Toon geen technische details aan eindgebruikers

3. Software Supply Chain Failures

Bij het ontwikkelen van software wordt veel gebruik gemaakt van externe frameworks en libraries. Dit versnelt de ontwikkeling en voorkomt dat complexe functionaliteit opnieuw gebouwd moet worden.

Deze componenten worden regelmatig bijgewerkt, zowel functioneel als op het gebied van beveiliging. Problemen ontstaan wanneer updates uitblijven. Bekende kwetsbaarheden blijven dan bestaan en maken de applicatie onnodig kwetsbaar. Ook ontbreekt vaak goed inzicht in gebruikte afhankelijkheden.

Het beheren van dependencies is complex. Je moet zicht hebben op:

• welke componenten en versies gebruikt worden
• welke kwetsbaarheden er zijn
• wat de impact is van updates (zoals breaking changes)

Het gebruik van externe componenten blijft aan te raden. Ze worden vaak onderhouden door grote communities, waardoor problemen snel worden gevonden en opgelost. Dit vraagt wel om actief beheer.

Mogelijke oplossingen en tips:

• Verwijder ongebruikte componenten
• Controleer regelmatig op (beveiligings)updates
• Automatiseer dependency checks (bijvoorbeeld met Dependabot of NPM audit)
• Zorg voor inzicht in dependencies (bijvoorbeeld via een Software Bill of Materials)
• Plan upgrades met breaking changes bewust in

4. Cryptographic Failures

Gegevens moeten goed beveiligd worden, zowel tijdens transport als opslag. De eisen verschillen per type data, bijvoorbeeld onder de AVG. In de meeste gevallen zal de data versleuteld verstuurd worden (HTTPS), maar ook bij de opslag van gegevens komt vaak versleuteling kijken.

Veelvoorkomende fouten:

• Onjuiste controle van certificaten
• Zwakke of hergebruikte sleutels
• Verouderde encryptiemethoden

Mogelijke oplossingen en tips:

• Classificeer data en bepaal passende beveiliging
• Sla geen onnodige gegevens op
• Gebruik moderne en sterke encryptie
• Versleutel ook data in opslag
• Gebruik sterke en unieke sleutels

5. Injection

Injection blijft een bekende en hardnekkige kwetsbaarheid, ondanks alle frameworks en tooling. Het gaat om situaties waarin gebruikersinput wordt uitgevoerd als code.

Hoewel deze categorie is gedaald, komt het nog steeds veel voor. De oorzaak is meestal hetzelfde: onvoldoende validatie van input en geen goede scheiding tussen data en uitvoering.

Bekende voorbeelden zijn SQL Injection, Cross-Site Scripting (XSS) en OS Command Injection. De impact kan groot zijn, zoals ongeautoriseerde toegang tot data of het overnemen van systemen.

Mogelijke oplossingen en tips:

• Valideer en sanitize input op de server
• Gebruik geparametriseerde queries
• Zorg voor scheiding tussen data en code

6. Insecure design

Deze categorie richt zich op het ontwerpproces. Beveiliging moet vanaf het begin worden meegenomen, niet pas tijdens implementatie. Bij een onveilig ontwerp ontstaan risico’s die later moeilijk te herstellen zijn.

In 2021 was dit een hoge nieuwe binnenkomer in de OWASP Top 10. Inmiddels is het onderwerp iets gezakt, wat laat zien dat organisaties stappen zetten, bijvoorbeeld door vaker threat modeling toe te passen en te werken volgens een secure development lifecycle.

Deze categorie draait minder om techniek en meer om proces. In de praktijk ligt de focus vaak op functionaliteit en infrastructuur, terwijl beveiliging pas later wordt meegenomen. Juist in de ontwerpfase worden de belangrijkste keuzes gemaakt.

Daarom moet de beveiligingsaanpak duidelijk zijn voordat er code wordt geschreven.

Mogelijke oplossingen en tips:

• Start met een threat modeling workshop
• Betrek stakeholders en breng risico’s en impact in kaart
• Neem security mee in backlog items
• Werk volgens een secure development lifecycle

7. Authentication Failures

Hier gaat het om problemen bij het vaststellen van wie de gebruiker is.

Denk aan zwakke wachtwoorden, onbeperkte loginpogingen of het ontbreken van multi-factor authenticatie. Als authenticatie niet goed geregeld is, vormt dat een directe ingang voor aanvallers.

Deze categorie is inhoudelijk weinig veranderd ten opzichte van 2021, maar blijft een belangrijk aandachtspunt.

Mogelijke oplossingen en tips:

• Gebruik multi-factor authenticatie
• Stel eisen aan wachtwoorden
• Bouw vertraging in bij mislukte loginpogingen
• Zorg dat testaccounts niet in productie terechtkomen

8. Software and Data integrity failures

Deze categorie is relatief nieuw (sinds 2021) en richt zich op vertrouwen in data en processen.

Het gaat bijvoorbeeld om het gebruik van externe bronnen zonder verificatie, onveilige CI/CD pipelines of het blind vertrouwen op data van de client.

In 2025 blijft deze categorie relevant, mede door de groeiende complexiteit van ontwikkel- en deployprocessen.

Mogelijke oplossingen en tips:

• Gebruik componenten met digitale signatures
• Werk met betrouwbare leveranciers
• Beveilig CI/CD pipelines
• Dwing code reviews af (4-ogen principe)
• Controleer data-integriteit

9. Security Logging and Alerting Failures

Dit onderwerp gaat over het loggen en monitoren van gebeurtenissen. Naast foutmeldingen is het essentieel om ook authenticatie te loggen. Bij een incident wil je weten wie wat heeft gedaan en wanneer.

Alleen loggen is niet genoeg. Logs moeten actief gemonitord worden, bij voorkeur geautomatiseerd. Zo kun je afwijkende patronen herkennen en tijdig alerts sturen naar de juiste personen.

Daarnaast is logging in veel gevallen verplicht volgens wet- en regelgeving zoals de AVG. Logs moeten dus veilig en zorgvuldig worden opgeslagen.

Bij beveiligingsproblemen kun je denken aan:

• Geen logging van (mislukte en geslaagde) logins
• Ontbrekende AVG-verplichte logging, zoals wijzigingen in persoonsgegevens
• Onveilige opslag van logs of onnodige opslag van persoonlijke data
• Geen alarmering bij verdachte gebeurtenissen

Mogelijke oplossingen en tips:

• Log zowel mislukte als geslaagde logins
• Richt monitoring en alarmering in, of gebruik tooling die dit ondersteunt
• Log volgens wet- en regelgeving:
  • Beperk het gebruik van persoonsgegevens in logs
  • Beperk toegang tot gevoelige logs via duidelijke protocollen
    

10. Mishandling of Exceptional Conditions

Dit is een nieuwe categorie in 2025. Het draait om het slecht afhandelen van fouten en uitzonderingen.

Wanneer exceptions niet goed worden verwerkt, kunnen systemen in onvoorspelbare toestanden komen. Dat kan leiden tot crashes, datalekken, Denial of Service (DoS) of zelfs het omzeilen van beveiliging.

Met de groei van complexe systemen en hoge belastingscenario’s is dit een logische toevoeging aan de lijst.

Mogelijke oplossingen en tips:

• Valideer alle input
• Vang exceptions op en handel ze af op detail niveau (dus niet vertrouwen op een foutafhandeling op hoog niveau)
• Retouneer geen foutdetails vanaf de server
• Beperk het aantal requests

Verdere overwegingen

De OWASP Top 10 is dus belangrijke kennis voor elke ontwikkelaar. Maar daar moet het natuurlijk niet bij blijven.

• Houd elkaar scherp en probeer de adviezen van de OWASP top 10 ook goed na te leven. 
• Werk volgens Security-by-Design en Privacy-by-Design.
• Start projecten met een Threat modeling workshop en herhaal dit periodiek aangezien er telkens nieuwe code en nieuwe bedreigingen bij komen.
• Het inhuren van gespecialiseerde Penetratietest bedrijven is ook zeker aan te raden.

Andere top 10-lijsten

Naast deze bekende “algemene” OWASP top 10 zijn er ook meer gerichte top 10-lijsten. Kijk bijvoorbeeld ook naar:

• OWASP Top 10 for Large Language Model Applications
• OWASP API Security Top 10

Meer informatie over beveiliging van webapplicaties?

De OWASP Top 10 is een belangrijk hulpmiddel, maar het blijft essentieel om professionele softwareontwikkelaars en/of beveiligingsspecialisten te betrekken bij de ontwikkeling en het onderhoud van softwareoplossingen.

Wil je meer inzicht in jouw softwaresituatie of je heb je vragen? Neem dan contact met ons op of bekijk onze securitytrainingen.