Wat is de OWASP Top 10?
Een ontwikkelaar pusht code op vrijdagmiddag. Tegen maandag heeft een aanvaller een API-parameter gemanipuleerd, klantgegevens benaderd en deze geëxfiltreerd via een kwetsbaarheid in toegangscontrole die met een eenvoudige autorisatiecontrole voorkomen had kunnen worden. Dit is het soort kwetsbaarheid dat de OWASP Top 10 wil voorkomen.
De OWASP Foundation definieert de OWASP Top 10 als "een standaard bewustmakingsdocument voor ontwikkelaars en webapplicatiebeveiliging. Het vertegenwoordigt een breed gedragen consensus over de meest kritieke beveiligingsrisico's voor webapplicaties." De lijst heeft meerdere edities doorgemaakt, en de introductie van 2025 bracht structurele wijzigingen die weerspiegelen hoe het applicatiebeveiligingslandschap is veranderd.
NIST en het MITRE CWE Content Team verwijzen formeel naar OWASP Top 10-categorieën in hun eigen raamwerken. Als u een beveiligingsprogramma beheert, applicaties bouwt of verantwoordelijk bent voor kwetsbaarheidsbeheer, is de OWASP Top 10 de basis die uw stakeholders verwachten dat u adresseert. Hier leest u wat de huidige editie omvat en hoe elke categorie van toepassing is op uw omgeving.
De OWASP Top 10-categorieën van 2025
De editie van 2025 heeft prioriteiten herschikt op basis van praktijkgegevens. Hier zijn alle tien categorieën in hun huidige volgorde, met de wijzigingen die relevant zijn voor uw beveiligingsprogramma.
A01: Broken Access Control
Nog steeds de belangrijkste categorie, met 3,73% van de geteste applicaties die ten minste één gerelateerde kwetsbaarheid vertonen. Broken access control stelt gebruikers in staat om buiten hun bedoelde rechten te handelen, bijvoorbeeld door een URL-parameter aan te passen om de gegevens van een andere gebruiker te bekijken, privileges te verhogen via JWT-tokenmanipulatie of functieniveau-beperkingen volledig te omzeilen. Dit omvat insecure direct object references (IDOR), ontbrekende toegangscontroles en CORS-misconfiguraties. SSRF, voorheen een aparte categorie, is nu hierin opgenomen.
A02: Security Misconfiguration
Gestegen van #5 in 2021, wat aangeeft hoeveel modern applicatiegedrag afhankelijk is van configuratie in plaats van code. Deze categorie omvat standaardwachtwoorden die niet zijn gewijzigd, onnodige diensten die zijn blootgesteld, uitgebreide foutmeldingen die stacktraces lekken en ontbrekende beveiligingsheaders. Cloudomgevingen en containerdeployments vergroten het risico omdat elke nieuwe dienst, API-gateway of Kubernetes-cluster een eigen configuratieoppervlak introduceert.
A03: Software Supply Chain Failures
De meest opvallende structurele wijziging in de editie van 2025. Voorheen beperkt tot "Kwetsbare en Verouderde Componenten", dekt deze categorie nu het volledige ecosysteem van softwareafhankelijkheden, buildsystemen en distributie-infrastructuur. Aanvallers richten zich steeds vaker op CI/CD-pijplijnen, ontwikkelaarstools, containerregistries en veelgebruikte open-sourcepakketten in plaats van direct op applicatiecode. Ondanks minder voorkomende gevallen in de data, heeft deze categorie de hoogste gemiddelde exploit- en impactscores in de dataset van 2025.
A04: Cryptographic Failures
Hernoemd van "Sensitive Data Exposure" om te focussen op de oorzaken in plaats van de symptomen. Deze categorie omvat gegevens die in cleartext worden verzonden, verouderde hashfuncties (MD5, SHA1), wachtwoorden die als cryptografische sleutels worden gebruikt en onvoldoende willekeurigheid. Wanneer cryptografische bescherming faalt, kunnen aanvallers inloggegevens onderscheppen tijdens transport, opgeslagen data ontsleutelen of authenticatietokens vervalsen. De naamswijziging weerspiegelt de bredere verschuiving van OWASP naar het aanpakken van de oorzaken van datalekken in plaats van het achteraf registreren van incidenten.
A05: Injection
Injection treedt op wanneer een applicatie niet-vertrouwde invoer doorstuurt naar een interpreter zonder juiste validatie of escaping, waardoor aanvallers ongewenste commando's kunnen uitvoeren. SQL-injectie, cross-site scripting (XSS), OS-commando-injectie en LDAP-injectie vallen allemaal onder deze categorie. Hoewel injection is gedaald van #3 naar #5 in de ranglijst van 2025, blijft het een van de categorieën met de meeste gerelateerde CVE's en een belangrijke oorzaak van datalekken bij gebrekkige inputverwerking.
A06: Insecure Design
Deze categorie richt zich op architecturale en ontwerpgerelateerde fouten in plaats van implementatiebugs. Een zwakke wachtwoord-resetflow, een ontbrekende autorisatiestap in een bedrijfsproces of het ontbreken van rate limiting op een gevoelig endpoint zijn allemaal ontwerpbeslissingen, en geen enkele veilige codering kan een fundamenteel onveilig ontwerp herstellen. OWASP heeft deze categorie geïntroduceerd om threat modeling, veilige ontwerppatronen en pre-code beveiligingsactiviteiten te benadrukken. De daling van #4 naar #6 in 2025 suggereert dat de sector hierin geleidelijk verbetert.
A07: Identification and Authentication Failures
Deze categorie omvat zwakheden waardoor aanvallers gebruikersidentiteiten kunnen compromitteren: credential stuffing, brute-force aanvallen op zwakke wachtwoorden, ontbrekende multi-factor authenticatie (MFA) en sessiebeheerfouten zoals voorspelbare sessietokens of onjuiste invalidatie. De analyse van OWASP merkt op dat het toenemende gebruik van gestandaardiseerde authenticatiekaders een positief effect heeft op het aantal incidenten, hoewel gestolen inloggegevens een van de meest voorkomende initiële toegangsvectoren bij datalekken blijven.
A08: Software or Data Integrity Failures
Deze categorie richt zich op aannames van vertrouwen bij software-updates, CI/CD-pijplijnen en dataserialisatie. Wanneer applicaties automatisch updaten zonder handtekeningen te verifiëren, afhankelijkheden ophalen uit niet-geverifieerde bronnen of niet-vertrouwde data deserialiseren zonder validatie, kunnen aanvallers malicious code injecteren die met volledige applicatierechten wordt uitgevoerd. De categorie omvat ook de integriteit van CI/CD-pijplijnen, waarbij een gecompromitteerde buildstap ongemerkt kwaadaardige artefacten naar productie kan brengen.
A09: Security Logging and Alerting Failures
De naamswijziging van "Security Logging and Monitoring Failures" is bewust: "Alerting" vervangt "Monitoring" omdat, volgens de introductie van 2025, "uitstekende logging zonder alerting van minimale waarde is" bij het identificeren van beveiligingsincidenten. Zonder bruikbare alerting gekoppeld aan logbronnen blijven inbreuken onopgemerkt terwijl het bewijs in opslag blijft. Deze categorie omvat ook onvoldoende logdetails, ontbrekende audit trails voor gevoelige acties en logs die authenticatie- of toegangscontrole-evenementen niet vastleggen.
A10: Mishandling of Exceptional Conditions
Nieuw in de editie van 2025, deze categorie behandelt wat er gebeurt wanneer applicaties onverwachte invoer, resource-tekorten, time-outs of interne fouten tegenkomen. Slechte exception handling kan gevoelige data lekken via uitgebreide stacktraces, beveiligingsmaatregelen omzeilen via fail-open logica of denial-of-service situaties veroorzaken. OWASP heeft 24 CWEs die voorheen verspreid waren over "code quality"-problemen samengevoegd in deze categorie, wat de groeiende erkenning weerspiegelt dat kwetsbare systemen die onveilig falen een aparte en uitbuitbare risicoklasse vormen.
De onderstaande tabel vat elke categorie samen en wat er is veranderd in de editie van 2025.
| # | Categorie | Wat is er veranderd in 2025 |
| A01 | Broken Access Control | Bevat nu SSRF, voorheen een aparte categorie |
| A02 | Security Misconfiguration | Gestegen van #5 in 2021 |
| A03 | Software Supply Chain Failures | Uitgebreid van "Vulnerable and Outdated Components" naar het volledige afhankelijkheidsecosysteem |
| A04 | Cryptographic Failures | Gedaald van #2; focus blijft op encryptieproblemen bij de bron |
| A05 | Injection | Gedaald van #3 naar #5; nog steeds een van de meest geteste categorieën |
| A06 | Insecure Design | Gedaald van #4 naar #6; adoptie van threat modeling in de sector verbetert |
| A07 | Authentication Failures | Ongewijzigde positie; lichte naamswijziging van "Identification and Authentication Failures" |
| A08 | Software or Data Integrity Failures | Ongewijzigde positie |
| A09 | Security Logging and Alerting Failures | Hernoemd; "Alerting" vervangt "Monitoring" om operationele noodzaak te weerspiegelen |
| A10 | Mishandling of Exceptional Conditions | Nieuwe categorie; vervangt de voormalige SSRF-entry |
Deze categorieën vormen de basis. Voordat u kijkt hoe u elk ervan kunt oplossen, is het nuttig te begrijpen waarom juist deze risico's organisatorisch gewicht hebben.
Waarom de OWASP Top 10 belangrijk is
De kloof tussen het ontdekken en uitbuiten van kwetsbaarheden wordt steeds kleiner, en webapplicaties blijven een primaire toegangspoort. Voor uw organisatie is de OWASP Top 10 om drie redenen belangrijk.
- Risicoprioritering. U kunt niet alles tegelijk oplossen. De Top 10 biedt een datagedreven startpunt gerangschikt op uitbuitbaarheid en impact, niet alleen op theoretische ernst.
- Regelgevingsafstemming. De NIST CSF onderhoudt crosswalk-mapping naar OWASP Top 10-varianten. Wanneer auditors of toezichthouders vragen naar uw applicatiebeveiligingsprogramma, is de OWASP Top 10 de gemeenschappelijke taal.
- Financiële realiteit. Beveiligingsfouten in toegangscontrole, misconfiguratie en injectie kunnen dure incidenten worden. De OWASP Top 10 helpt uw teams zich te richten op de kwetsbaarheidsklassen die het meest waarschijnlijk operationele en zakelijke impact veroorzaken.
Begrijpen waarom deze risico's belangrijk zijn is de eerste stap. De volgende stap is weten hoe u elk ervan op code- en configuratieniveau aanpakt.
Hoe OWASP Top 10-kwetsbaarheden te voorkomen
Elke OWASP Top 10-categorie heeft specifieke preventiestappen die uw teams direct kunnen implementeren.
- A01: Broken access control. Hanteer deny-by-default op alle endpoints. Valideer rechten server-side bij elk verzoek en consolideer naar één toegangscontroleroutine die consistent wordt toegepast in de codebase. Schakel directory listing uit en zorg dat CORS-beleid alleen vertrouwde domeinen toestaat.
- A02: Security misconfiguration. Verwijder standaardwachtwoorden, schakel ongebruikte diensten en functies uit en automatiseer configuratie-audits over alle omgevingen. Houd beveiligingsheaders actueel en zorg dat foutmeldingen generiek zijn in plaats van stacktraces te tonen.
- A03: Software supply chain failures. Pin afhankelijkheden op specifieke versies en verifieer integriteit met cryptografische handtekeningen of checksums. Onderhoud een software bill of materials (SBOM), audit CI/CD-plugins en ontwikkelaarstools, en monitor kwetsbaarheidsdatabases op bekende kwetsbaarheden in uw afhankelijkheidsboom.
- A04: Cryptographic failures. Gebruik actuele encryptiestandaarden (TLS 1.2+, AES-256) en stop met verouderde algoritmen zoals MD5 en SHA1. Sla wachtwoorden op met adaptieve hashing-functies zoals bcrypt of Argon2. Classificeer data op gevoeligheid zodat u het juiste beschermingsniveau toepast op de juiste assets.
- A05: Injection. Gebruik geparametriseerde queries voor alle databasebewerkingen. Valideer en sanitiseer alle gebruikersinvoer en escape output voor de specifieke rendercontext (HTML, JavaScript, SQL). Pas content security policies toe om XSS-impact te beperken.
- A06: Insecure design. Voer threat modeling uit voordat u code schrijft, stel abuse case-tests op naast functionele tests en pas veilige ontwerppatronen toe uit de OWASP Proactive Controls. Ontwerpfouten zijn goedkoper te herstellen in de architectuur dan in productie.
- A07: Authentication failures. Dwing MFA af, implementeer login throttling met een maximum aantal pogingen en gebruik gestandaardiseerde authenticatiekaders. Invalideer sessies correct bij uitloggen en wachtwoordwijziging.
- A08: Software or data integrity failures. Onderteken alle buildartefacten, containerimages en software-updates cryptografisch. Valideer deserialisatie-invoer en beperk schrijfrechten in CI/CD-pijplijnen tot geautoriseerde rollen.
- A09: Security logging and alerting failures. Stel bruikbare alertdrempels in voor authenticatiefouten, toegangscontroleovertredingen en privilege-escalatiepogingen. Test dat alerts daadwerkelijk afgaan onder reële omstandigheden, niet alleen dat logs worden verzameld.
- A10: Mishandling of exceptional conditions. Definieer veilige faalmodi die gesloten falen en toegang weigeren bij fouten. Geef gebruikers generieke foutmeldingen terwijl u intern gedetailleerde diagnostiek logt. Behandel null-waarden, resource-uitputting en onverwachte inputtypes expliciet.
Preventie per categorie adresseert de technische oplossingen. Het opschalen van deze oplossingen binnen uw organisatie is waar implementatie-uitdagingen ontstaan.
Uitdagingen en veelgemaakte fouten bij OWASP Top 10-implementatie
Het operationaliseren van de OWASP Top 10 in een productieomgeving met honderden applicaties, tientallen ontwikkelteams en continue deploymentcycli is waar implementatie vaak misgaat. Dit zijn de patronen die de meeste schade veroorzaken.
- De Top 10 behandelen als een pass/fail-checklist. OWASP beschrijft de Top 10 expliciet als een bewustmakingsgids, niet als een beveiligingsprogramma. Voor verificatietesten raadt OWASP de ASVS aan. Voor alleen supply chain-dekking is de Top 10 slechts "af en toe" voldoende.
- Gefragmenteerde toegangscontrole-implementaties. Het Proactive Controls-project waarschuwt voor meerdere toegangscontrole-implementaties verspreid over een codebase. Eén foutieve implementatie blijft uitbuitbaar, zelfs als alle andere correct zijn.
- Standaard permissieve configuraties. Geen deny-by-default afdwingen op REST API's en webhooks betekent dat elk niet-afgedekt endpoint impliciet toegankelijk is. Dit geldt voor cloudservices, Kubernetes RBAC en API-gateways.
- Autorisatie op schaal. Authenticatie verbetert, maar toegangscontrole niet. De sector lost "wie ben je?" op, maar worstelt met "wat mag je doen?" over API's en microservices.
- Logging zonder alerting. U kunt terabytes aan logdata in uw SIEM hebben, maar als niemand bruikbare alertdrempels instelt, blijven incidenten onopgemerkt terwijl het bewijs in opslag blijft.
- Uitsluitend vertrouwen op enumeratiegebaseerde scanning. Enumeratiegebaseerde tools vinden alleen wat u al weet te zoeken. Logische fouten, nieuwe misconfiguraties en architecturale zwakheden vereisen gedragsanalyse, niet alleen signature matching.
Deze patronen blijven bestaan wanneer beveiligingsprogramma's de OWASP Top 10 behandelen als een eenmalige audit in plaats van een doorlopend operationeel proces.
OWASP Top 10 Best Practices
Naast oplossingen per categorie helpen deze programmabrede praktijken u de OWASP Top 10 te operationaliseren binnen uw organisatie.
- Bouw een gecentraliseerde bibliotheek voor beveiligingscontroles. Volgens programmabegeleiding definieert u gedeelde, herbruikbare bibliotheken voor authenticatie, autorisatie, inputvalidatie en cryptografie. Wanneer elk team zijn eigen implementatie bouwt, ontstaan inconsistenties die uitbuitbare gaten creëren.
- Koppel Proactive Controls aan uw ontwikkelworkflow. De Proactive Controls bieden een ontwikkelaarsgerichte aanvulling op de risicogerichte Top 10. C1 (Access Control) koppelt aan A01, C3 (Input Validation) aan A05, C5 (Secure Defaults) aan A02. Geef uw ontwikkelaars specifieke controles om te implementeren, niet alleen risico's om te vermijden.
- Gebruik OWASP ASVS als verificatiebasis. Vervang ad-hoc penetratietesten door gestructureerde, ASVS-eisen gekoppeld aan elke Top 10-categorie. ASVS biedt testbare criteria in CSV- en JSON-formaat voor programmatische integratie.
- Integreer met NIST SSDF voor regelgevingsafstemming. NIST SP 800-218 verwijst expliciet naar OWASP ASVS, OWASP SAMM en OWASP SCVS als aanvullende raamwerken en sluit aan bij de vereisten van Executive Order 14028.
Deze praktijken vormen de programmatische basis. Testen valideert dat uw preventiecontroles werken zoals verwacht.
Hoe te testen op de OWASP Top 10
Geen enkel hulpmiddel dekt alle tien categorieën. Effectief testen op de OWASP Top 10 combineert statische analyse, dynamische testen en samenstellingsanalyse om risico's op code-, runtime- en afhankelijkheidsniveau te dekken.
- Static application security testing (SAST) scant broncode op injectiepatronen, cryptografische zwakheden en authenticatiefouten vóór deployment. SAST detecteert problemen vroeg in de ontwikkelcyclus wanneer oplossingen het goedkoopst zijn.
- Dynamic application security testing (DAST) test draaiende applicaties op toegangscontrolegaten, misconfiguraties en fouten in foutafhandeling door echte aanvalstraffic te simuleren op live endpoints. OWASP ZAP is een veelgebruikt open-source DAST-hulpmiddel dat wordt onderhouden door de OWASP-community.
- Software composition analysis (SCA) identificeert bekende kwetsbaarheden in externe libraries, frameworks en containerimages door uw afhankelijkheidsboom te vergelijken met gepubliceerde kwetsbaarheidsdatabases.
- Penetratietesten valideert uw specifieke omgeving en detecteert logische fouten en architecturale zwakheden die door geautomatiseerde tools worden gemist. Koppel bevindingen uit penetratietesten aan ASVS-eisen voor gestructureerde verificatie.
De onderstaande tabel koppelt elke testmethode aan de OWASP Top 10-categorieën die het meest direct worden gedekt.
Methode | Gedekte categorieën | Beste gebruik |
SAST | A04, A05, A07 | Tijdens ontwikkeling, vóór code wordt gemerged |
| DAST | A01, A02, A10 | Op draaiende applicaties in staging of productie |
| SCA | A03, A08 | Tijdens build en bij elke afhankelijkheidsupdate |
| Penetratietesten | Alle 10 categorieën | Periodieke validatie, na grote releases |
Door deze methoden te combineren krijgt u dekking over alle tien OWASP Top 10-categorieën. Autonome tooling overbrugt de kloof tussen wat u vindt en hoe snel u reageert.
Belangrijkste punten
De OWASP Top 10 is het standaard bewustmakingsraamwerk van de sector voor webapplicatiebeveiliging-risico's, in 2025 geüpdatet met uitgebreide supply chain-dekking en een nieuwe nadruk op alerting naast logging. Broken Access Control blijft de belangrijkste categorie. Elke categorie heeft specifieke, implementeerbare preventiestappen, van deny-by-default toegangscontrole tot cryptografische verificatie van artefacten.
Effectieve implementatie vereist gecentraliseerde beveiligingscontroles, gelaagde testen via SAST, DAST en SCA, en autonome onderzoeksmogelijkheden die het gat tussen exploitsnelheid en reactiesnelheid dichten.
Veelgestelde vragen
De OWASP Top 10 is een standaard bewustmakingsdocument dat wordt gepubliceerd door de OWASP Foundation en de meest kritieke beveiligingsrisico's voor webapplicaties identificeert.
Op basis van praktijkgegevens over kwetsbaarheden en community-enquêtes biedt de lijst een consensusgedreven rangschikking die ontwikkelaars, securityteams en auditors gebruiken als basis voor applicatiebeveiligingsprogramma's. De huidige editie is uitgebracht in 2025.
De OWASP Top 10 volgt geen vast releaseschema. Updates worden gepubliceerd wanneer er voldoende nieuwe kwetsbaarheidsdata en input uit de community zijn om een herziene rangschikking te rechtvaardigen.
Eerdere edities zijn uitgebracht in 2013, 2017, 2021 en 2025. Elke update weerspiegelt verschuivingen in exploitatiepatronen in de praktijk, veranderingen in applicatiearchitectuur en nieuwe methoden voor dataverzameling, in plaats van alleen theoretische risicoprojecties.
De Top 10 is een bewustmakingsdocument dat is ontworpen om de meest kritieke risicocategorieën voor webapplicaties te benadrukken. De ASVS (Application Security Verification Standard) biedt gestructureerde, testbare verificatie-eisen op drie zekerheidsniveaus, waardoor het geschikt is voor securitytesten en code review.
OWASP zelf adviseert ASVS voor ontwerpreviews en beveiligingsbeoordelingen, waarbij de Top 10 als instappunt wordt gepositioneerd en ASVS als het verificatiekader.
De Top 10 van webapplicaties omvat API-relevante categorieën, met name Broken Access Control (A01) en Injection (A05). OWASP onderhoudt echter een aparte API Security Top 10 met categorieën die specifiek zijn voor API-autorisatie, rate limiting en objectniveau-toegangscontrole.
Verschillende toonaangevende API-risico's houden direct verband met autorisatiefouten die overeenkomen met A01. Organisaties met aanzienlijke API-blootstelling dienen beide lijsten te behandelen om voldoende dekking te waarborgen.
De methodologie van 2025 breidde de geanalyseerde dataset uit en introduceerde een bredere databijdragencyclus naast het community-onderzoek van OWASP voor toekomstgerichte risico's.
De wegingsformule bleef exploitatiegraad en technische impact in balans brengen, terwijl deze een bredere kwetsbaarheidscorpus weerspiegelde. Deze methodologische uitbreiding, en niet alleen verschuivende dreigingspatronen, veroorzaakte verschillende verschuivingen in de ranglijst, waaronder de stijging van Security Misconfiguration en de toevoeging van Mishandling of Exceptional Conditions als nieuwe categorie.
Nee. OWASP geeft expliciet aan dat de Top 10 een bewustmakings- en instaptrainingsmiddel is. Voor alleen supply chain-beveiliging wordt de Top 10 als slechts "Af en toe" voldoende gekenmerkt.
Een volledig programma moet OWASP ASVS voor verificatie, OWASP SAMM voor volwassenheidsbeoordeling, NIST SSDF voor SDLC-integratie en continue runtimebescherming omvatten om risico's af te dekken waarvoor de Top 10 nooit is ontworpen.
