In dit artikel7
Wat is de OWASP Top 10?
Application security gaat over het veilig ontwerpen, bouwen, testen en beheren van software. Het is een onderdeel van het vakgebied cybersecurity. De OWASP Top 10 is een bekend startpunt, omdat de lijst kort is en in gewone taal beschrijft waar het mis kan gaan.
OWASP beschrijft de lijst als een standaard bewustwordingsdocument voor ontwikkelaars en voor de beveiliging van webapplicaties. Het geeft een brede consensus weer over de ernstigste beveiligingsrisico's voor webapplicaties. Voor een beginner is het een goede eerste lijst om te kennen.
De Top 10 is een lijst van risicocategorieën. Het is geen testplan en geen compliancenorm. Wie een applicatie tot in detail wil toetsen, gebruikt ASVS, en wie wil weten hoe volwassen het ontwikkelproces is, gebruikt SAMM. Die twee komen verderop aan bod.
De editie van 2025 is de 8e uitgave van de lijst. De vorige editie is die van 2021. De pagina van OWASP over de editie van 2025 geeft de actuele tekst.
Welke tien categorieën staan in de OWASP Top 10:2025?
De lijst bestaat uit tien categorieën, in de volgorde die OWASP aanhoudt. De namen staan in het Engels zoals OWASP ze gebruikt.
Plaats en naam | Wat het is | Voorbeeld |
|---|---|---|
A01 Broken Access Control | Gebruikers handelen buiten hun bedoelde rechten, bijvoorbeeld door een URL of API-aanroep aan te passen | Andermans account bekijken of wijzigen door een ander identificatienummer op te geven |
A02 Security Misconfiguration | Een systeem, applicatie of cloudservice is onjuist ingesteld | Foutmeldingen die stack traces tonen |
A03 Software Supply Chain Failures | Fouten in de hele softwareketen, niet alleen bekende kwetsbaarheden in componenten | Componenten met bekende kwetsbaarheden, waarmee de categorie in 2013 begon |
A04 Cryptographic Failures | Cryptografie ontbreekt, is niet sterk genoeg of sleutels lekken | Lekken van cryptografische sleutels |
A05 Injection | Onvertrouwde invoer wordt als opdracht naar een interpreter gestuurd | SQL-injectie |
A06 Insecure Design | Fouten in ontwerp en architectuur, die een perfecte implementatie niet kan herstellen | Een beveiligingsmaatregel die nooit is ontworpen |
A07 Authentication Failures | Fouten in het vaststellen van identiteit en in sessies | Hard-coded wachtwoorden of inloggegevens |
A08 Software or Data Integrity Failures | Software, code en data worden niet op integriteit gecontroleerd | Deserialisatie van onvertrouwde data |
A09 Security Logging & Alerting Failures | Logging is onvoldoende, of er volgt geen actie op relevante logregistraties | Gevoelige gegevens in logbestanden |
A10 Mishandling of Exceptional Conditions | Fouten worden verkeerd afgehandeld, bijvoorbeeld door bij een fout toegang te geven | Failing open: bij een fout toegang geven in plaats van weigeren |
De volgorde weerspiegelt het onderzoek van OWASP, maar elke categorie telt in de praktijk. Een applicatie die goed is ingericht op A01 kan nog kwetsbaar zijn voor A05.
Een verzonnen voorbeeld bij A01: een webshop toont bestellingen via een adres als /bestelling/1042. Als de applicatie alleen controleert of je bent ingelogd en niet of bestelling 1042 van jou is, kan een klant met een ander nummer andermans bestelling zien. OWASP noemt dit een insecure direct object reference. De oplossing is een eigenaarscontrole op de server, niet het nummer verbergen. Het beheer van rechten en inloggen hoort bij A01 en A07, zie identity and access management.
Een verzonnen voorbeeld bij A05: een zoekveld waarvan de tekst rechtstreeks in een databasequery wordt geplakt. Door speciale tekens kan iemand de query veranderen. De oplossing is de query parameteriseren en de invoer valideren. OWASP schrijft dat code review en geautomatiseerd testen samen de beste kans geven om injectie te vinden, en dat SAST-, DAST- en IAST-tools in de CI/CD-pijplijn kunnen helpen. Voor het testen van webapplicaties zie pentest tools uitgelegd.
A06 hangt samen met threat modeling. Fouten in het ontwerp vind je moeilijk met een scan op de code, en beter door vooraf na te denken over wat er mis kan gaan. Lees meer over threat modelling. Vacatures met threat modelling staan op de skillpagina.
A03 raakt het beheer van leveranciers en afhankelijkheden: welke bibliotheken gebruikt de applicatie en wie houdt ze bij. Zie vulnerability management voor het bijhouden van kwetsbaarheden.
Wat is er veranderd sinds de editie van 2021?
Ten opzichte van 2021 zijn er twee nieuwe categorieën en één samenvoeging. A03 Software Supply Chain Failures is een uitbreiding van A06:2021 Vulnerable and Outdated Components, tot de hele softwareketen. A10 Mishandling of Exceptional Conditions is nieuw. Server-Side Request Forgery (SSRF) is opgegaan in A01 Broken Access Control.
A02 Security Misconfiguration steeg van plaats 5 naar plaats 2. Twee namen veranderden. De naam van A07 is korter geworden, zonder "Identification and", zodat die beter aansluit bij de 36 CWE's in deze categorie. A09 is hernoemd van Security Logging and Monitoring Failures naar Security Logging & Alerting Failures, zodat de nadruk op alerting ligt.
De volgorde en de namen veranderen per editie. Wie een oudere lijst of artikel leest, ziet dus andere nummers.
Waar komt de lijst vandaan en wat is ze niet?
De editie van 2025 is gebaseerd op een dataset waarin 589 CWE's zijn geanalyseerd. Daarvan zijn 248 CWE's ondergebracht in de tien categorieën. Bijdragers leverden data over meer dan 2,8 miljoen applicaties. Acht categorieën zijn op basis van die data gekozen, de andere twee komen uit een enquête onder de community. OWASP noemt de lijst op data gebaseerd, maar niet blindelings door data gestuurd.
De lijst is een startpunt voor gesprek en training. Een team kan niet voldoen aan de Top 10, en een test die de categorieën naloopt, is geen volledige beveiligingstest. De lijst zegt ook niet hoe waarschijnlijk een risico in jouw applicatie is. Dat moet je zelf nagaan.
Wat is ASVS?
De Application Security Verification Standard (ASVS) is een lijst met beveiligingseisen. Architecten, ontwikkelaars, testers, beveiligingsprofessionals, toolleveranciers en afnemers kunnen hem gebruiken om veilige applicaties te definiëren, te bouwen, te testen en te verifiëren. De huidige versie is ASVS 5.0.0 van mei 2025. OWASP noemt drie toepassingen: als maatstaf, als richtlijn voor wat je bouwt en bij inkoop als basis voor eisen in contracten. OWASP zelf raadt aan ASVS te gebruiken als leidraad voor beveiligingseisen. Vacatures over het testen en verifiëren van applicaties staan onder security testing.
ASVS kent drie niveaus, L1, L2 en L3, die in diepte en complexiteit toenemen. Level 1 bevat het minimum, ongeveer 20 procent van de eisen. Level 2 is waar de meeste applicaties naar moeten streven: ongeveer 50 procent van de eisen, dus samen met L1 ongeveer 70 procent. Level 3 bevat de laatste ongeveer 30 procent, vooral defense-in-depth-maatregelen en controles die lastig te implementeren zijn.
De organisatie kiest het niveau op basis van de eigen risico's. ASVS schrijft het niveau niet voor, en het is geen wettelijke eis. Voor implementatievragen verwijst ASVS naar de OWASP Cheat Sheet Series, en voor testvragen naar de Web Security Testing Guide.
Wat is SAMM?
SAMM, het Software Assurance Maturity Model, is een zelfbeoordelingsmodel waarmee een organisatie haar softwarebeveiliging kan meten en verbeteren. Het kent vijf bedrijfsfuncties met samen vijftien beveiligingspraktijken. Elke praktijk heeft drie volwassenheidsniveaus. Meer over het model staat op de SAMM-pagina van OWASP.
Bedrijfsfunctie | Beveiligingspraktijken |
|---|---|
Governance | Strategy & Metrics, Policy & Compliance, Education & Guidance |
Design | Threat Assessment, Security Requirements, Secure Architecture |
Implementation | Secure Build, Secure Deployment, Defect Management |
Verification | Architecture Assessment, Requirements-driven Testing, Security Testing |
Operations | Incident Management, Environment Management, Operational Management |
ASVS beantwoordt de vraag wat de applicatie moet kunnen. SAMM beantwoordt de vraag hoe volwassen het proces is om veilige software te bouwen.
Hoe gebruikt een security professional dit in het werk?
Een application security engineer kan de Top 10 en ASVS gebruiken bij reviews en trainingen en helpt teams veilig te bouwen, met reviews, training en tooling in de CI/CD-pijplijn. Zie de vacatures voor application security engineers, de rolgids en de werkgeverspagina voor wie deze functie zoekt.
Een penetration tester kan de categorieën gebruiken als structuur voor bevindingen. Het overzicht van de soorten testtools staat in pentest tools uitgelegd. Zie de vacatures voor penetration testers en de rolgids.
Een security architect kijkt naar het ontwerp, dus naar A06. Die rol kan threat modeling inzetten om ontwerpfouten vroeg te vinden. Zie de vacatures voor security architecten.
Een SOC-analist kan baat hebben bij goede applicatielogging, omdat A09 gaat over de logging en alerting die nodig zijn om op relevante meldingen te reageren. Zonder logging die iemand opvolgt, kan een organisatie een aanval missen. Lees over de SIEM om te zien hoe die meldingen verzameld worden.
Een ontwikkelaar kan training krijgen op de categorieën en leert ze herkennen in de eigen code. Stel dat een code-review een ontbrekende autorisatiecontrole (A01) vindt: zo leert de ontwikkelaar de categorie in de eigen code herkennen.
OWASP raadt ook aan om met SAMM een bestaand ontwikkelproces te beoordelen en te verbeteren. Voor een modern applicatiebeveiligingsprogramma noemt OWASP vijf stappen:
- Een risicogebaseerd portfolio van applicaties en API's.
- Een basis van beleid en standaarden, met herbruikbare controles en training per rol.
- Beveiligingsactiviteiten in elke fase van de ontwikkelcyclus, zoals threat modeling, secure code review en penetratietesten.
- Educatie, bijvoorbeeld een security champion-programma en oefenomgevingen als OWASP Juice Shop en WebGoat.
- Zicht voor het management, met metrics.
Wat is de OWASP Top 10?
De OWASP Top 10 is een bewustwordingsdocument over de tien ernstigste beveiligingsrisico's voor webapplicaties. De huidige editie is OWASP Top 10:2025, de 8e uitgave van de lijst.
Welke categorieën staan op nummer 1 en nummer 2?
Op plaats 1 staat A01 Broken Access Control, dat gaat over het afdwingen van beleid zodat gebruikers niet buiten hun rechten handelen. Op plaats 2 staat A02 Security Misconfiguration, over systemen, applicaties en cloudservices die onjuist zijn ingesteld.
Is de OWASP Top 10 een norm waar je aan moet voldoen?
Nee. OWASP noemt de lijst een bewustwordingsdocument. Voor eisen waartegen je een applicatie kunt toetsen bestaat ASVS, en voor de volwassenheid van het ontwikkelproces bestaat SAMM.
Wat is het verschil tussen de Top 10, ASVS en SAMM?
De Top 10 maakt bewust waar de risico's zitten. ASVS levert beveiligingseisen in drie niveaus om een applicatie tegen te toetsen. SAMM beoordeelt het proces rondom het bouwen van veilige software.
Welke functies werken ermee?
Application security engineers, penetration testers, security architecten en SOC-analisten kunnen er elk op een eigen manier mee werken, zoals hierboven beschreven. Zie de rolgidsen en vacatures voor de details per functie.