OWASP Top 10:2025 voor webapplicatie-pentests: wat verandert en waar wij op testen

De OWASP Top 10 is al ruim twintig jaar het meest geciteerde referentiekader voor de beveiliging van webapplicaties. In januari 2026 verscheen de editie 2025: de eerste grote inhoudelijke herziening sinds 2021. OWASP baseerde de lijst op een analyse van meer dan 175.000 CVE-records en bijna 600 onderliggende zwakheidsklassen (CWE's), aangevuld met een community-enquête voor risico's die nog niet breed in de data zichtbaar zijn. Voor iedereen die een webapplicatie laat pentesten, of zelf de uitvraag van een pentest voorbereidt, is het de moeite waard om te weten wat er is veranderd en hoe een pentester deze categorieën in de praktijk toetst.

In dit artikel lopen we de tien categorieën van 2025 langs vanuit het perspectief van de pentester: wat de categorie betekent, hoe wij die tijdens een webapplicatie-pentest aanvallen en welk type bevinding je in een rapport mag verwachten. We sluiten af met de relatie tussen de OWASP Top 10 en een volwaardige pentest, want daar bestaat in de praktijk veel verwarring over.

Wat er is veranderd ten opzichte van 2021

De grootste wijzigingen zitten in twee nieuwe categorieën en een aantal herschikkingen. Software Supply Chain Failures (A03) is nieuw en vervangt en verbreedt de oude categorie 'Vulnerable and Outdated Components'. De focus verschuift daarmee van losse kwetsbare libraries naar de hele toeleveringsketen: build-pipelines, package-repositories, afhankelijkheden van afhankelijkheden en de integriteit van wat er uiteindelijk in productie draait. Mishandling of Exceptional Conditions (A10) is eveneens nieuw en gaat over de manier waarop applicaties omgaan met fouten, uitzonderingen en onverwachte invoer. Verder is Server-Side Request Forgery niet langer een aparte categorie maar opgegaan in Broken Access Control, en zijn enkele categorieën hernoemd. Broken Access Control blijft onverminderd op nummer één staan.

A01 — Broken Access Control

Verbroken toegangscontrole is opnieuw het meest voorkomende en vaak meest impactvolle probleem. Het gaat erom dat een gebruiker iets kan doen of zien waartoe hij geen recht heeft. In een pentest is dit doorgaans onze eerste en meest productieve aanvalslijn. We maken twee accounts aan met verschillende rechten en proberen systematisch of gebruiker A bij de gegevens van gebruiker B kan. Klassieke voorbeelden zijn het ophogen van een object-ID in de URL (insecure direct object reference), het rechtstreeks benaderen van een beheerfunctie zonder de juiste rol, en het manipuleren van een verborgen formulierveld dat de prijs of de gebruikersrol bepaalt. Sinds 2025 valt ook SSRF onder deze categorie: het misbruiken van de server om interne systemen of cloud-metadata-endpoints te benaderen.

A02 — Security Misconfiguration

Verkeerde configuratie is breed en alomtegenwoordig. Standaardwachtwoorden die niet zijn gewijzigd, uitgebreide foutmeldingen die stacktraces tonen, ongebruikte poorten en services, te ruime CORS-instellingen en ontbrekende beveiligingsheaders. Tijdens een pentest brengen we de aanwezigheid en kwaliteit van headers als Content-Security-Policy, Strict-Transport-Security en X-Content-Type-Options in kaart, controleren we op toegankelijke beheerinterfaces en zoeken we naar directory listing en achtergelaten debugfunctionaliteit. Dit zijn vaak laaghangende bevindingen die met weinig moeite te verhelpen zijn, maar samen het aanvalsoppervlak flink vergroten.

A03 — Software Supply Chain Failures

De nieuwe ketencategorie erkent dat moderne applicaties voor het grootste deel uit code van derden bestaan. Een kwetsbaarheid in een veelgebruikte library, een gecompromitteerd npm-pakket of een onveilige build-pipeline kan een verder degelijk gebouwde applicatie onderuithalen. In onze beoordeling kijken we naar bekende kwetsbaarheden in afhankelijkheden (via een software bill of materials), naar de manier waarop afhankelijkheden worden vastgezet en geverifieerd, en naar de beveiliging van de pipeline zelf. Voor organisaties is dit het moment om een SBOM-proces in te richten en niet alleen de eigen code, maar ook de herkomst van externe componenten serieus te nemen.

A04 — Cryptographic Failures

Deze categorie gaat over de bescherming van gevoelige gegevens, zowel onderweg als in rust. Denk aan ontbrekende of zwakke versleuteling, verouderde TLS-configuraties, het gebruik van zwakke hash-algoritmen voor wachtwoorden en het lekken van gevoelige data in URL's of logs. In een pentest controleren we de TLS-instellingen, kijken we of cookies de attributen Secure en HttpOnly hebben en zoeken we naar gevoelige informatie die onversleuteld wordt verzonden of opgeslagen.

A05 — Injection

Injectie omvat SQL-injectie, command injection en cross-site scripting (XSS), dat sinds 2021 onderdeel is van deze categorie. De rode draad is dat gebruikersinvoer onvoldoende wordt gescheiden van commando's of queries. We testen invoervelden, URL-parameters, headers en API-payloads met op de context afgestemde payloads en beoordelen of de applicatie geparametriseerde queries en correcte output-encoding toepast. Een succesvolle SQL-injectie behoort nog steeds tot de zwaarste bevindingen, omdat die vaak directe toegang tot de database betekent.

A06 — Insecure Design

Onveilig ontwerp is een fundamenteel andere categorie dan een implementatiefout: het probleem zit in het ontwerp zelf, niet in de code. Een wachtwoordherstelproces zonder rate limiting, een betaalflow waarin de prijs aan de clientzijde wordt bepaald, of het ontbreken van een tegenmaatregel tegen geautomatiseerd misbruik. Dit soort zwakheden ontdek je niet met een scanner; ze vragen om begrip van de business logic. Hier komt de meerwaarde van een ervaren pentester duidelijk naar voren, en hier ligt ook de brug naar threat modeling vroeg in het ontwikkelproces.

A07 — Authentication Failures

Authenticatie- en sessiezwakheden gaan over het bewijzen van identiteit en het beheren van sessies. We testen op zwak wachtwoordbeleid, het ontbreken van bescherming tegen credential stuffing en brute force, voorspelbare of niet-geroteerde sessietokens, en ontbrekende multifactorauthenticatie op gevoelige functies. Ook kijken we of sessies correct ongeldig worden gemaakt bij uitloggen en of tokens niet uitlekken via verkeerde opslag.

A08 — Software or Data Integrity Failures

Deze categorie draait om het vertrouwen in code en data zonder dat de integriteit is geverifieerd. Denk aan onveilige deserialisatie, auto-updates zonder handtekeningverificatie en CI/CD-processen die niet-geverifieerde artefacten uitrollen. We beoordelen of de applicatie data van buiten vertrouwt zonder controle en of de keten van code naar productie integriteitscontroles kent.

A09 — Security Logging and Alerting Failures

Onvoldoende logging en alertering maakt het lastig om aanvallen te detecteren en erop te reageren. Het is een categorie die je in een pentest niet altijd zichtbaar 'breekt', maar wel beoordeelt: worden inlogpogingen, toegangsfouten en verdachte handelingen vastgelegd, en leidt dat tot tijdige signalering? In de editie 2025 is alertering nadrukkelijk in de naam opgenomen, omdat loggen zonder opvolging weinig waarde heeft.

A10 — Mishandling of Exceptional Conditions

De tweede nieuwe categorie gaat over hoe applicaties omgaan met fouten en randgevallen. Verkeerde foutafhandeling kan leiden tot het lekken van informatie via foutmeldingen, tot fail-open-gedrag waarbij een mislukte controle toch toegang verleent, en tot onverwacht gedrag bij ongeldige invoer. Tijdens een pentest sturen we bewust onverwachte en malforme invoer om te zien hoe robuust de applicatie reageert en of fouten veilig (fail-closed) worden afgehandeld.

De OWASP Top 10 is geen pentest-checklist

Een hardnekkig misverstand is dat 'testen op de OWASP Top 10' gelijkstaat aan een volwaardige pentest. Dat is niet zo. De Top 10 is een bewustwordingsdocument met de tien meest voorkomende risicocategorieën, geen volledige teststandaard. Een serieuze webapplicatie-pentest volgt eerder de OWASP Web Security Testing Guide (WSTG) of de Application Security Verification Standard (ASVS), die honderden concrete testgevallen bevatten. De Top 10 is een uitstekend startpunt en communicatiemiddel richting management, maar een rapport dat zich uitsluitend tot de Top 10 beperkt, mist veel context — denk aan applicatiespecifieke business-logic-fouten die buiten elke categorie vallen.

Van bevinding naar herstel en retest

De waarde van een pentest zit niet in de lijst met bevindingen, maar in wat erna gebeurt. Een goed rapport beschrijft per bevinding de impact, de exploiteerbaarheid en een concreet hersteladvies, en kent een prioritering op basis van risico in plaats van enkel een CVSS-score. Na het herstel hoort een retest: een gerichte hercontrole of de kwetsbaarheden daadwerkelijk en volledig zijn opgelost. Wij leveren standaard een retest binnen een afgesproken termijn, omdat een bevinding pas gesloten is als die verifieerbaar weg is.

Secure Audit voert webapplicatie-pentests uit waarin geautomatiseerde tooling en handmatige expertise worden gecombineerd, met rapportage die aansluit op zowel de OWASP Top 10 als de diepere WSTG/ASVS-testgevallen. Neem contact op voor een vrijblijvend gesprek over de scope van een pentest voor jouw applicatie.