AI AGENT & CYBERSECURITYPlan een test
01 / Modellaag
02 / Stacklaag
03 / Bedrijf
Plan een testEnglish

02 / StacklaagWEB & API

Pentest van je webapplicatie: we testen de logica, niet alleen de code.

Een websitepentest, of pentest van een webapplicatie, is een geautoriseerde, gesimuleerde aanval op je applicatie door ethical hackers. Die toont aan welke kwetsbaarheden echt misbruikt kunnen worden, gevolgd door een rapport met bewijs, risico-inschatting en concrete oplossingen. We besteden de testdagen aan wat scanners niet kunnen volgen: bedrijfslogica, autorisatie tussen gebruikers en klanten, en workflows in meerdere stappen, gekoppeld aan de twaalf categorieën van de OWASP Web Security Testing Guide.

Plan een testBekijk een voorbeeldrapport

Voor SaaS-teams met een vragenlijst van een klant, een auditperiode of een release die verandert wie wat kan zien.

Pakket
WEB & API
Bandbreedte, excl. btw
EUR 5.000 tot 15.000
Testdagen
4 tot 10

SESSIES / FICTIE / TWEE ROLLEN, EEN APPLICATIE06 REGELS GELEZEN / 1 GEVONDENVOORBEELD

SESSIE AROL: KLANT

  1. Eigen claimsTOEGESTAAN
  2. Notities adviseurTOEGESTAAN
  3. BetalingenGEWEIGERD

SESSIE BROL: ADVISEUR

  1. Eigen claimsTOEGESTAAN
  2. Notities adviseurTOEGESTAAN
  3. BetalingenGEWEIGERD

SESSIE A / NOTITIES ADVISEUR / ROL NIET GECONTROLEERD / WSTG-ATHZ

Dezelfde drie schermen via twee rollen: de klant komt bij de notities van de adviseur, omdat de server de rol nooit controleert. Wij testen elke rol tegen elke functie, op de server, niet alleen in het menu.

Hoe ziet een bevinding in een webapplicatie eruit?

Niet elke bevinding is kritiek, en het rapport zegt dat gewoon. Deze is laag, komt uit de fictieve opdracht in ons voorbeeldrapport, en krijgt toch het request en de oplossing mee.

VOORBEELD / FICTIEVE KLANT / ECHT FORMAT

SAMPLE-01 / F-06

LAAGCVSS-B 2.3STACKLAAGWSTG-SESS

Sessies in het portaal blijven langer geldig dan het beleid zegt

Impact op het bedrijf
Een sessie die open blijft op een gedeeld apparaat, blijft een dag bruikbaar.
Bewijs
REQUEST REQ-21, BIJLAGE B De requests die het reproduceren, met beide testaccounts erbij.
CVSS v4.0-vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Oplossingsprincipe
Dwing de time-out bij inactiviteit af op de server, niet alleen in de browser.
Hertest
OPGELOST 2026-09-24 Sessies verlopen nu na 30 minuten inactiviteit.
Het format dat elke bevinding in ons rapport krijgt. De klant en de bevinding zijn fictief; de velden niet. Lees F-06 in het voorbeeldrapport.

Wat testen we in een webapplicatie?

De twaalf categorieën van de Web Security Testing Guide zijn de ondergrens, niet het plan. Elke regel hieronder is er één van; de testdagen gaan naar de regels die volgens je dreigingsmodel het zwaarst wegen.1

Werken je klanten of auditors met een lijst eisen in plaats van een lijst tests, dan koppelen we bevindingen ook aan de OWASP Application Security Verification Standard.2

Elke regel is een categorie uit onze testcatalogus. De ids linken naar het framework dat ze definieert.
Nr.CategorieWat we controlerenGekoppeld aan
01Autorisatie en scheiding tussen klantenOf elk object, elke actie en elke beheerroute controleert wie er vraagt, over rollen en over klanten heen.
02Bedrijfslogica en integriteit van processen in meerdere stappenOf workflows in de verkeerde volgorde, herhaald, of met waarden die de interface nooit zou sturen, kunnen worden doorlopen.
03Sessiebeheer: tokens, cookies, uitloggen en time-outTokens en cookies, uitloggen en time-out, en wat er met open sessies gebeurt als een wachtwoord of rol verandert.
04Authenticatie: inloggegevens, herstel en blokkeringInloggen, herstel, meerfactorauthenticatie en blokkering, ook de flows die niemand gebruikt totdat er iets misgaat.
05Identiteitsbeheer: rollen, registratie en provisioningRegistratie, uitnodigingen en provisioning: wie een account kan aanmaken, zich bij het account van een andere klant kan aansluiten of zichzelf een rol kan geven.
06Invoervalidatie en omgang met injectieHoe invoer wordt afgehandeld op weg naar queries, templates, bestanden en andere systemen.
07Beveiliging aan de clientkant: DOM, cross-originbeleid en framingCode aan de clientkant, cross-originbeleid, framing, en wat de browser in zijn eentje moet afdwingen.
08Configuratie- en deploymentbeheerDeployment en configuratie: securityheaders, bereikbare beheerinterfaces, debugmodi en vergeten omgevingen.
09Blootgestelde informatie en het in kaart brengen van de applicatieWat de applicatie een buitenstaander over zichzelf vertelt voordat er iemand inlogt.
10Foutafhandeling zonder informatielekkenOf foutmeldingen stacktraces, interne paden of data prijsgeven.
11Transportbeveiliging en cryptografische keuzesTransportbeveiliging, en of gevoelige data beschermd is waar die wordt opgeslagen en waar die naartoe gaat.
12Review van GraphQL en het API-oppervlakHet API-oppervlak achter de interface, inclusief GraphQL en de endpoints die de frontend niet meer gebruikt.

Buiten scope Load- en denial-of-servicetests, social engineering van je medewerkers, en diensten van derden waarvoor je ons geen schriftelijke toestemming kunt geven.

Hoe verloopt een pentest van een webapplicatie?

Een pentest heeft een vaste tijd. Een aanvaller niet. Dus besteden we die tijd aan denken.

  1. 01In kaart

    Onze tooling brengt de applicatie in kaart; een mens leest de kaart.

    Crawlen, verkeer vastleggen en een inventaris van elke route, rol en parameter draaien op onze eigen tooling. Daarna leest een mens het resultaat zoals een aanvaller dat zou doen: welke objecten van wie zijn, en welke workflows geld, data of rechten verplaatsen.

  2. 02Elke rol

    We testen met een account per rol, bij twee klanten.

    Grey box is de standaard: testaccounts voor elke rol bij minstens twee klanten. Autorisatiefouten zie je niet vanuit één account; ze komen boven als de ene gebruiker om de objecten van een andere vraagt, en als de grens tussen twee klanten wordt overschreden.

  3. 03Bedrijfslogica

    We doorlopen je workflows in de verkeerde volgorde.

    Bevindingen in de bedrijfslogica beginnen bij de vraag wat de applicatie aanneemt: dat stappen op volgorde gebeuren, dat een prijs van de server komt, dat een uitnodiging één keer wordt gebruikt. Een scanner weet niet dat die aannames bestaan; wij testen ze een voor een.

  4. 04Bevestigen en koppelen

    We bewijzen elke bevinding en verbinden de kleine.

    Lage bevindingen die samen een echt pad vormen, rapporteren we als dat pad, met de requests die elke stap laten zien.

  5. 05Ernst en rapport

    We beoordelen de ernst in CVSS v4.0 en schrijven de oplossing.

    Bij elke bevinding staan de WSTG-categorie, een CVSS v4.0-vector met score, de exacte requests en een oplossingsprincipe dat je engineers op de hele klasse fouten kunnen toepassen, niet alleen op het ene endpoint dat wij vonden.3

Wat kost een pentest van een webapplicatie?

Een pentest van een webapplicatie of API kost in Nederland doorgaans EUR 5.000 tot 15.000, exclusief btw, en ons pakket Web en API zit in dezelfde band. De offerte na het scopinggesprek bepaalt het precieze bedrag.4

02 / Stack Pentest

WEB & API

EUR 5.000 tot 15.000

DOORGAANS 4 TOT 10 TESTDAGEN

Wat de prijs bepaalt

  • Rollen, klanten en gebruikerspaden in scope
  • De omvang van het API-oppervlak achter de interface
  • Grey box- of black box-toegang
  • Staging, of alleen productie binnen afgesproken vensters

Bekijk alle prijzen

Rapport
Scope, methode, datums, bevindingen met bewijs, ernst in CVSS v4.0, framework-ids, oplossingsadvies en de status na de hertest.
Verklaring
Eén pagina die scope, datums en de status na de hertest bevestigt, voor klanten die het resultaat willen zonder de bevindingen.
Dekkingsmatrix
Elke categorie in scope gemarkeerd als getest, niet van toepassing of buiten scope, zodat ook de gaten op papier staan.
Bewijs
De exacte requests achter elke bevinding, klaar om opnieuw af te spelen.

De opdracht, in het kort.

4 tot 10 testdagen op staging waar het kan, binnen de spelregels die je vooraf tekent. Daarna het rapport en een verklaring van één pagina, en de hertest zodra je de bevindingen hebt opgelost. Elke stap, van het scopinggesprek tot het regressiepakket, staat in de werkwijze.

Vragen over het testen van webapplicaties.

Wat is een websitepentest?

Een websitepentest is een geautoriseerde, gesimuleerde aanval op je webapplicatie die aantoont welke zwakke plekken echt misbruikt kunnen worden. Testers werken als echte gebruikers van elke rol, volgen de workflows en het autorisatiemodel, en rapporteren elke bevestigde bevinding met bewijs, een beoordeling in CVSS v4.0 en een oplossing die je engineers kunnen toepassen.

Volgen jullie de OWASP WSTG of de ASVS?

Allebei, voor verschillende taken. De Web Security Testing Guide bepaalt wat we testen, categorie voor categorie, en bij elke bevinding staat de WSTG-categorie. De ASVS is een lijst eisen; werken je klanten of auditors daarmee, dan koppelen we onze bevindingen ook aan die eisen, zodat de twee documenten op elkaar aansluiten.

Testen jullie ingelogd of van buitenaf?

Standaard ingelogd, als elke rol. Fouten in autorisatie en bedrijfslogica komen pas boven als de ene ingelogde gebruiker kan bereiken wat van een andere is, dus vragen we om testaccounts per rol bij minstens twee klanten. Alleen van buitenaf testen kan ook, en dan vermeldt het rapport wat die test niet kon zien.

Wat is het verschil tussen een pentest en een DAST-scan?

Een dynamische scanner stuurt bekende patronen en meldt wat er verkeerd uitziet. Een pentest bevestigt wat misbruikt kan worden, volgt de workflows en rechten die een scanner niet kan nabootsen, en verbindt kleine problemen tot één echt pad. Laat je scanner bij elke release draaien; boek een pentest als iemand moet weten wat een aanvaller echt zou kunnen.

Hoe lang duurt een pentest van een webapplicatie?

Doorgaans 4 tot 10 testdagen, binnen een venster dat in de spelregels is afgesproken. De rollen en klanten in scope, het aantal workflows dat geld, data of rechten verplaatst, en de omvang van de API achter de interface bepalen het aantal. Het scopinggesprek legt het vast voordat de test begint.