Hoe pentest je een website? Het volledige proces in 6 fases
Een website pentest is geen scan die je even aanzet en laat lopen. Het is een gestructureerd onderzoek waarin een tester stap voor stap uitzoekt hoe ver een aanvaller op jouw site zou komen, en welk pad hij daarvoor gebruikt.
In dit artikel lees je hoe dat proces verloopt. Welke fases een pentester doorloopt, waarop hij test, wat je zelf al kunt afvangen en waar handwerk het verschil maakt met een geautomatiseerde tool.
Wat een website pentest precies inhoudt
Bij een webapplicatie pentest valt een tester met toestemming je website aan binnen een vooraf afgebakende scope. Hij zoekt kwetsbaarheden, buit ze gecontroleerd uit en toont aan wat een aanvaller ermee zou bereiken.
Dat laatste is het verschil met een vulnerability scan. Een scanner meldt dat een component verouderd is. Een pentester laat zien dat hij via dat component een sessietoken van een andere gebruiker overneemt en bij de bestellingen van je klanten komt. Het eerste is een signaal, het tweede is bewijs.
De meeste testers werken volgens de OWASP Web Security Testing Guide. Die richtlijn bevat ruim negentig testgevallen, verdeeld over twaalf categorieën, elk met een eigen code zoals WSTG-ATHN-01 voor authenticatietesten. Daarmee wordt een test herhaalbaar en toetsbaar in plaats van een zoektocht op gevoel.
De zes fases van een website pentest
Vrijwel elke serieuze test doorloopt dezelfde volgorde. De diepgang per fase verschilt, de volgorde zelden.
1. Scope en toestemming vastleggen
Voordat er één request over de lijn gaat, ligt vast wat binnen de test valt en wat erbuiten. Welke domeinen en subdomeinen, welke API-endpoints, welke omgeving (productie of acceptatie), welke accounts en rollen de tester krijgt, en op welke tijdstippen er getest wordt.
Ook je hostingpartij hoort hiervan te weten. Veel providers zien een pentest als aanvalsverkeer en grijpen in. Daarnaast is toestemming juridisch de basis: zonder schriftelijke opdracht valt binnendringen in een systeem onder computervredebreuk, ook met de beste bedoelingen.
2. Verkenning en aanvalsoppervlak in kaart brengen
De tester bouwt een kaart van je site. Alle pagina’s, formulieren, parameters, cookies, headers, API-calls, redirects en integraties met derden. Hij inventariseert welke technologie eronder draait: CMS, framework, versies, plug-ins, WAF, CDN en certificaten.
Daarbij hoort ook wat er buiten je site over je te vinden is. Subdomeinen die je vergeten bent, een oude acceptatieomgeving die nog publiek staat, een repository met een sleutel erin, of documenten die via zoekmachines geïndexeerd zijn. Deze fase bepaalt de rest van de test: wat hier niet gevonden wordt, wordt later ook niet getest.
3. Geautomatiseerd scannen als vertrekpunt
Tools zoals Burp Suite en OWASP ZAP crawlen de applicatie en signaleren het laaghangend fruit: ontbrekende securityheaders, verouderde libraries met bekende CVE’s, zwakke TLS-configuratie, verdachte foutmeldingen.
Deze stap kost weinig tijd en levert een startlijst op. Een scanner ziet echter geen bedrijfslogica. Hij weet niet dat gebruiker A geen inzage hoort te hebben in dossier B. Daarom is dit een vertrekpunt, nooit het eindpunt. Welke tooling waarvoor dient, lees je in ons overzicht van de beste pentest tools.
4. Handmatig testen per categorie
Hier zit het werk. De tester loopt systematisch de WSTG-categorieën af en test elk onderdeel met de hand.
- Authenticatie: bruteforcebescherming, gebruikersnaam-enumeratie via verschillende foutmeldingen, wachtwoordbeleid, MFA-bypass, OAuth- en SSO-implementatie.
- Autorisatie: kan een klant met een aangepast ID het dossier van een ander openen? Kan een gewone gebruiker een beheerdersfunctie aanroepen?
- Sessiebeheer: cookieflags, sessietimeouts, sessiefixatie, gedrag na uitloggen.
- Invoervalidatie: SQL-injectie, cross-site scripting, command injection, template injection, onveilige deserialisatie.
- Bedrijfslogica: een bestelling met een negatief aantal, een kortingscode die oneindig herbruikbaar is, een betaalstap die je kunt overslaan.
- Configuratie: directory listing, standaardwachtwoorden, debugpagina’s, blootliggende beheerpanelen.
Draait er een API onder je frontend, dan hoort die apart in scope. Bij een API pentest ligt de nadruk op autorisatie per object en per functie, precies waar geautomatiseerde tools het vaakst blind zijn.
5. Uitbuiten en bewijs vastleggen
Een vermoeden is geen bevinding. De tester bewijst dat de kwetsbaarheid werkt en legt vast hoe: het request, de respons, een screenshot, een reproduceerbaar stappenplan.
Daarbij hoort terughoudendheid. Toont een SQL-injectie zich, dan haalt een professionele tester de databaseversie op en stopt daar. Hij dumpt geen klantgegevens om zijn punt te maken. Datzelfde geldt voor uitbuiting die de site plat kan leggen: dat gebeurt in overleg, of in het geheel niet.
Losse bevindingen worden ook aan elkaar geknoopt. Een informatielek van lage ernst plus een zwakke sessiecontrole kan samen tot volledige overname leiden. Die keten is waar de meeste waarde zit.
6. Rapportage en hertest
Het rapport bevat per bevinding: wat er speelt, hoe het reproduceerbaar is, welk risico eraan hangt (vaak via CVSS) en welke herstelactie past. Daarnaast een managementsamenvatting voor wie geen code leest.
Na het herstel volgt een hertest op de gevonden punten. Pas dan weet je dat de fix werkt en heb je bewijs richting een auditor of klant. Wil je zien hoe zo’n document is opgebouwd, bekijk dan ons voorbeeld van een pentest rapport.
Waar test een pentester op? De OWASP Top 10 (2025)
OWASP publiceerde de Top 10:2025 in november 2025 tijdens Global AppSec in Washington, met de definitieve versie in januari 2026. De lijst is gebaseerd op ruim 175.000 CVE-records en 248 gekoppelde CWE’s. Twee categorieën zijn nieuw en SSRF is opgegaan in Broken Access Control.
| Code | Categorie | Wat dat op je site betekent |
|---|---|---|
| A01 | Broken Access Control | Gebruikers zien of doen dingen die buiten hun rechten vallen. Inclusief SSRF. |
| A02 | Security Misconfiguration | Van #5 naar #2. Debugstand aan, standaardaccounts, te ruime CORS. |
| A03 | Software Supply Chain Failures | Nieuw. Je plug-ins, pakketten, buildpipeline en registries. |
| A04 | Cryptographic Failures | Verkeer of opslag zonder deugdelijke versleuteling, verouderde hashes. |
| A05 | Injection | SQL-injectie, XSS, command injection. |
| A06 | Insecure Design | Het ontwerp zelf laat misbruik toe, los van de code. |
| A07 | Authentication Failures | Zwakke inlogflows, ontbrekende MFA, sessieproblemen. |
| A08 | Software and Data Integrity Failures | Updates en data zonder integriteitscontrole. |
| A09 | Logging and Alerting Failures | Hernoemd. Loggen zonder bruikbare meldingen levert weinig op. |
| A10 | Mishandling of Exceptional Conditions | Nieuw. Foutafhandeling die te veel prijsgeeft of de verkeerde kant op faalt. |
Opvallend detail uit de data: Software Supply Chain Failures heeft de hoogste incidentie (5,19%) en tegelijk weinig CVE-dekking. Aanvallen op afhankelijkheden lopen dus voor op de signatures van scanners. Voor een WordPress- of Magento-site met tientallen plug-ins is dat direct relevant.
Video: de stappen van een webapplicatie pentest
Wat je zelf kunt doen voordat een tester begint
Een deel van de bevindingen in een eerste pentest is voorspelbaar. Door die vooraf af te vangen, koop je testtijd vrij voor het werk dat er echt toe doet.
- Werk je CMS, thema, plug-ins en pakketten bij en verwijder wat je niet gebruikt.
- Zet securityheaders aan: Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy.
- Controleer je TLS-configuratie en schakel verouderde protocollen uit.
- Haal debugstanden, testaccounts en publieke acceptatieomgevingen offline.
- Zet MFA op alle beheerdersaccounts.
- Loop je gebruikersrollen na en verwijder rechten die niemand nodig heeft.
- Maak een verse back-up en controleer of terugzetten werkt.
Wat je hiermee niet afvangt: bedrijfslogica, autorisatie tussen gebruikers, ketens van kleine zwakheden en alles wat een creatieve aanvaller verzint. Daar begint het handwerk.
Zelf testen of uitbesteden?
Je kunt een scanner op je eigen site loslaten en de checklist hierboven aflopen. Dat verhoogt je basisniveau en is verstandig werk.
Twee zaken pleiten voor een externe partij. Ten eerste blindheid: wie de applicatie heeft gebouwd, test onbewust rond de aannames die hij zelf heeft gemaakt. Ten tweede bewijskracht. Een auditor, verzekeraar of zakelijke klant accepteert een zelfgemaakte scanuitdraai zelden als aantoonbaar bewijs.
De hoeveelheid voorkennis die je meegeeft bepaalt de diepgang. In ons artikel over black box, grey box en white box pentesten lees je welke variant bij welke vraag past.
Hoeveel tijd kost een website pentest?
De doorlooptijd hangt af van het aantal rollen, de hoeveelheid functionaliteit en de vraag of een API meegaat. Grove richtlijn voor het testwerk zelf:
| Type site | Indicatie testdagen |
|---|---|
| Brochuresite met contactformulier | 2 tot 3 dagen |
| Webshop met klantaccounts en betaalflow | 4 tot 7 dagen |
| SaaS-portaal met meerdere rollen en API | 8 dagen en meer |
Reken daarnaast op rapportagetijd en een hertest. Wat dat in jouw situatie betekent, zie je op onze pagina met tarieven.
Hoe vaak laat je je website testen?
Jaarlijks is voor de meeste organisaties een werkbaar ritme. Daarnaast zijn er momenten die om een test vragen ongeacht de kalender: een nieuwe applicatie live, een herbouw van de authenticatie, een migratie naar een andere hostingomgeving of een uitbreiding met een betaalprovider.
Val je onder een kader zoals ISO 27001, PCI-DSS of de Cyberbeveiligingswet, dan ligt de frequentie vaak al vast in je eigen beleid of in de norm. Wat elk kader gemeen heeft: het jaar erna telt de vorige test niet meer als bewijs.
Veelgestelde vragen
Mag ik mijn eigen website pentesten?
Ja, op je eigen systemen mag je testen. Draait je site bij een hostingpartij of in de cloud, dan raak je infrastructuur van een ander. Vraag hen vooraf toestemming en leg die schriftelijk vast.
Gaat mijn website plat tijdens een pentest?
De kans is klein en nooit nul. Daarom spreek je een testvenster af, houdt de tester contact met je beheerder en blijven zwaar destructieve technieken buiten scope zolang je daar niet expliciet om vraagt. Een verse back-up hoort bij de voorbereiding.
Test je op productie of op acceptatie?
Productie geeft het eerlijkste beeld, omdat configuratie, WAF en data daar echt zijn. Acceptatie geeft ruimte om door te pakken zonder gevolgen voor klanten. Een gangbare middenweg: testen op een acceptatieomgeving die één op één gelijk is aan productie, met een beperkte verificatie op productie.
Is een pentest hetzelfde als een securityscan?
Nee. Een scan draait geautomatiseerd en meldt bekende zwakheden. Een pentest verifieert die met de hand, zoekt naar zaken die geen scanner ziet en toont de gevolgen aan. Beide hebben nut, ze beantwoorden een andere vraag.
Wat krijg ik na afloop?
Een rapport met bevindingen op risiconiveau, bewijsmateriaal, reproduceerbare stappen en hersteladvies per punt. Daarnaast een managementsamenvatting en een hertest nadat je hebt hersteld.
Je website laten testen
Wil je weten hoe ver iemand op jouw site komt en wat dat je zou schelen? Neem contact op voor een intake. We bepalen samen de scope, het testvenster en de vorm die past bij de vraag die je hebt.
