AI AGENT & CYBERSECURITYScope a test
01 / Model layer
02 / Stack layer
03 / Company
Scope a testNederlands

02 / Stack layerWEB & API

Web application penetration testing that reads your logic.

A web application penetration test is an authorized, simulated attack on your application by security specialists that proves which vulnerabilities are actually exploitable, followed by a report with evidence, risk ratings and concrete fixes. We spend the testing days where scanners cannot follow: business logic, authorization between users and tenants, and multi-step workflows, mapped to the twelve categories of the OWASP Web Security Testing Guide.

Scope a testSee a sample report

For SaaS teams with a customer questionnaire, an audit window, or a release that changes who can see what.

Package
WEB & API
Range, excl. VAT
EUR 5,000 to 15,000
Testing days
4 to 10

SESSIONS / FICTION / TWO ROLES, ONE APPLICATION06 ROWS READ / 1 FOUNDSAMPLE

SESSION AROLE: CUSTOMER

  1. Own claimsALLOWED
  2. Adviser notesALLOWED
  3. Payout settingsDENIED

SESSION BROLE: ADVISER

  1. Own claimsALLOWED
  2. Adviser notesALLOWED
  3. Payout settingsDENIED

SESSION A / ADVISER NOTES / ROLE NOT CHECKED / WSTG-ATHZ

The same three screens through two roles: the customer reaches the adviser’s notes because the server never checks the role. We test every role against every function, on the server, not only in the menu.

What does a web finding look like?

Not every finding is critical, and the report says so plainly. This one is low, from the fictional engagement in our sample report, and it still comes with the request and the fix.

SAMPLE / FICTIONAL CLIENT / REAL FORMAT

SAMPLE-01 / F-06

LOWCVSS-B 2.3STACK LAYERWSTG-SESS

Portal sessions stay valid longer than the stated policy

Business impact
A session left open on a shared device stays usable for a day.
Evidence
REQUEST REQ-21, APPENDIX B The requests that reproduce it, with both test accounts named.
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
Fix principle
Enforce the idle timeout on the server, not only in the browser.
Retest
FIXED 2026-09-24 Sessions now expire after 30 minutes idle.
The format every finding takes in our report. The client and the finding are fiction; the fields are not. Read F-06 in the sample report.

What do we test in a web application?

The twelve categories of the Web Security Testing Guide are the floor, not the plan. Each row below is one of them; the testing days go to the rows your threat model says matter most.1

When your customers or auditors work from a requirement list instead of a test list, we map findings to the OWASP Application Security Verification Standard as well.2

Every row is a category in our test catalogue. Ids link to the framework that defines them.
No.CategoryWhat we checkMapped to
01Authorization and tenant isolationWhether every object, action and admin route checks who is asking, across roles and across tenants.
02Business logic and multi-step workflow integrityWhether workflows can be run out of order, repeated, or completed with values the interface would never send.
03Session management: tokens, cookies, logout and timeoutTokens and cookies, logout and timeout, and what happens to open sessions when a password or a role changes.
04Authentication: credentials, recovery and lockoutLogin, recovery, multi-factor and lockout, including the flows nobody uses until something goes wrong.
05Identity management: roles, registration and provisioningRegistration, invitations and provisioning: who can create an account, join a tenant or grant themselves a role.
06Input validation and injection handlingHow input is handled on its way to queries, templates, files and other systems.
07Client-side security: DOM, cross-origin policy and framingClient-side code, cross-origin policies, framing, and what the browser is trusted to enforce on its own.
08Configuration and deployment managementDeployment and configuration: security headers, exposed admin interfaces, debug modes and forgotten environments.
09Information exposure and application mappingWhat the application tells an outsider about itself before anyone logs in.
10Error handling without information leakageWhether errors give away stack traces, internal paths or data.
11Transport security and cryptographic choicesTransport security, and whether sensitive data is protected where it is stored and where it is sent.
12GraphQL and API surface reviewThe API surface behind the interface, including GraphQL and the endpoints the frontend stopped using.

Out of scope Load and denial-of-service testing, social engineering of your staff, and third-party services you cannot give us written permission to test.

How does a web application pentest run?

A pentest is time-boxed. Attackers are not. So we spend the box on thinking.

  1. 01Map

    Our instruments map the application; a person reads the map.

    Crawling, traffic capture and an inventory of every route, role and parameter run on our own tooling. A person then reads the result the way an attacker would: which objects belong to whom, and which workflows move money, data or permissions.

  2. 02Every role

    We test with an account per role, in two tenants.

    Grey box is the default: test accounts for every role in at least two tenants. Authorization flaws are invisible from a single account; they show up when one user asks for another user’s objects, and when a tenant boundary is crossed.

  3. 03Business logic

    We run your workflows in the wrong order.

    Business logic findings come from asking what the application assumes: that steps happen in sequence, that a price comes from the server, that an invitation is used once. A scanner does not know these assumptions exist; we test them one by one.

  4. 04Confirm and chain

    We prove each finding and connect the small ones.

    Low findings that combine into a real path are reported as that path, with the requests that show each step.

  5. 05Rate and report

    We rate severity in CVSS v4.0 and write the fix.

    Each finding carries its WSTG category, a CVSS v4.0 vector and score, the exact requests, and a fix principle your engineers can apply to the whole class of bug, not only the one endpoint we found.3

What does a web application penetration test cost?

A web application or API penetration test in the Netherlands typically costs EUR 5,000 to 15,000, excluding VAT, and our Web & API package sits in the same band. The quote after the scoping call sets the exact figure.4

02 / Stack Pentest

WEB & API

EUR 5,000 to 15,000

TYPICALLY 4 TO 10 TESTING DAYS

What moves the price

  • Roles, tenants and user journeys in scope
  • The size of the API surface behind the interface
  • Grey box or black box access
  • Staging, or production only within agreed windows

See all prices

Report
Scope, method, dates, findings with evidence, severity in CVSS v4.0, framework ids, fix guidance and retest status.
Attestation letter
One page that confirms scope, dates and retest status, for customers who need the result without the findings.
Coverage matrix
Every category in scope marked tested, not applicable or out of scope, so the gaps are written down too.
Evidence
The exact requests behind every finding, ready to replay.

The engagement, in short.

4 to 10 testing days on staging where we can, under the rules of engagement you sign first. Then the report and a one-page letter, and the retest once you have fixed. Every step, from the scoping call to the regression pack, is in the method.

Questions about web application testing.

What is a web application penetration test?

A web application penetration test is an authorized, simulated attack on your application that proves which weaknesses are actually exploitable. Testers work as real users of every role, follow the workflows and the authorization model, and report each confirmed finding with evidence, a CVSS v4.0 rating and a fix your engineers can apply.

Do you follow the OWASP WSTG or the ASVS?

Both, for different jobs. The Web Security Testing Guide structures what we test, category by category, and every finding carries its WSTG category. The ASVS is a list of requirements; when your customers or auditors work from it, we map our findings to its requirements as well, so the two documents line up.

Do you test logged in or from the outside?

Logged in, as every role, by default. Authorization and business logic flaws only show up when one authenticated user can reach what belongs to another, so we ask for test accounts per role in at least two tenants. An outside-only test is possible, and the report states what it could not see.

How is a pentest different from a DAST scan?

A dynamic scanner sends known patterns and reports what looks wrong. A penetration test confirms what is exploitable, follows the workflows and permissions a scanner cannot model, and connects small issues into one real path. Keep your scanner for every release; book a pentest when someone needs to know what an attacker could actually do.

How long does a web application pentest take?

Typically 4 to 10 testing days of testing, inside a window agreed in the rules of engagement. The roles and tenants in scope, the number of workflows that move money, data or permissions, and the size of the API behind the interface set the number. The scoping call fixes it before the test starts.