Design Partner Program
GUIDE · WEB APPLICATION SECURITY

Web application penetration testing: what it proves, and how long that lasts.

A good pentest finds what scanners can't: broken business logic, chained weaknesses, authorization gaps. It also describes one version of your app, on the days it was tested. This guide covers how to scope a web app pentest, what to expect from it, and how to keep its findings true after the next release.

LAST PENTEST REPORTapp.example.com
Testing window 10 days
Findings reported 23
Releases shipped since 41
Routes changed since 38%
Fixes verified by retest 9 / 23
The report is accurate. It's just about an application you no longer run.
01 · WHAT A PENTEST COVERS

Web Application Penetration Testing Methodology, Phase by Phase

Most providers follow the OWASP Web Security Testing Guide or a close variant. The phases are consistent; depth and skill vary a lot.

01

Reconnaissance

Map domains, subdomains, technologies and exposed services.

Automation handles it well
02

Application mapping

Crawl routes, parameters, roles and workflows; build the attack surface model.

Automation helps; a human decides
03

Authentication & session

Login, MFA, password reset, session fixation, token handling and logout.

Automation helps; a human decides
04

Authorization

Horizontal and vertical access: can one user act as another, or as an admin?

Where human testers earn their fee
05

Input handling

Injection, XSS, SSRF, deserialization, file upload and template injection.

Automation handles it well
06

Business logic

Workflow skips, race conditions, price and quantity tampering, abuse of features.

Where human testers earn their fee
07

Chaining & impact

Combine low-severity issues into a path to real impact, and prove it.

Where human testers earn their fee
08

Reporting & retest

Findings with reproduction steps, severity and fixes, then a retest of remediations.

Automation helps; a human decides
Automation handles it well Automation helps; a human decides Where human testers earn their fee
02 · PENTEST VS SCANNER VS CONTINUOUS

Penetration Testing vs Vulnerability Scanning vs Continuous Validation

Three approaches that answer different questions. Most programs need a pentest and at least one of the others.

QUESTION
DAST scanner
Manual pentest
Continuous validation
Injection and known vulnerability classes
Strong Broad and fast across every route.
Strong Fewer routes, deeper per route.
Strong Proves which are exploitable.
Business logic flaws
Weak No model of the intended workflow.
Strong Where experienced testers excel.
Partial Known patterns and retests of past findings.
Authorization across roles
Weak Usually one identity per scan.
Strong Within the roles provided.
Strong Every role, every release.
Chained, multi-step attacks
Weak Findings judged one at a time.
Strong Creative chaining is the point.
Partial Approved chains from the scenario library.
How often it runs
Every build Fits CI/CD.
1 to 2 times a year Scheduled engagements.
Every release Plus a schedule.
False positives
Common Needs triage.
Low Each finding hand-verified.
Low Each finding reproduced with evidence.
Fix verification
Rescan Same blind spots.
Retest window Often one, time-limited.
Automatic Finding reruns until closed.

Generalized by approach. Individual products and providers vary.

03 · COVERAGE DECAY

How Fast Does a Web App Pentest Go Stale?

One year of a typical SaaS release cycle. The orange bar is the share of today's application that the last pentest actually tested. Play it through.

MONTH ··
RELEASES SHIPPED 0
SINCE LAST PENTEST ··
APP COVERED BY REPORT ··
JanFebMarAprMayJunJulAugSepOctNovDec
Tested by last pentest Tested by continuous validation
Press play to step through a year of weekly releases.
00:00 / 00:20

Illustrative model · assumes weekly releases and a mid-year pentest · 20 s replay

04 · WHAT A FINDING LOOKS LIKE

Business Logic Example: A Discount Applied Twice

Every request is valid. Every response is a 200. The flaw is in the order of the steps, which is exactly what scanners don't model and good pentesters look for first.

Illustrative finding · synthetic data

Checkout · promotion reuse via race condition WSTG-BUSL-05 · CWE-362 · CWE-840
High Validated
SETUP
Identity: shopper_basic. Cart total $120.00. Single-use promotion code SPRING25 issued to this account.
NORMAL
Applying the code once works as designed.POST /cart/promo { "code": "SPRING25" } → 200 total: $95.00
RACE
The same request is sent twice in parallel, a few milliseconds apart.POST /cart/promo ×2 (parallel) → 200, 200
RESULT
Both requests passed the "already used" check before either recorded the redemption.total: $70.00 (discount applied twice)
IMPACT
Repeatable on every single-use code. Checkout completed in the test store only; no real order placed.
SCANNER
The weekly DAST scan covers this route and has never flagged it: no payload, no error, no signature.
Fix and retest: redeem promotions inside a single transaction with a uniqueness constraint; the parallel request pair is replayed from the evidence record and only one succeeds.
05 · SCOPING

How to Scope a Web Application Penetration Test

Most disappointing pentests were scoped badly, not tested badly. Settle these six things before the engagement starts.

Testing safely in production →
01

Applications and routes

Exact hostnames, paths and APIs in scope, and anything explicitly out, such as third-party payment pages.

02

Accounts for every role

At least two accounts per role, including admin, so horizontal and vertical access can both be tested.

03

Environment

Production or a staging copy that matches it. Agree on what test data testers may create and change.

04

Testing approach

Black, grey or white box. Grey box with documentation usually gives the most value per tester-day.

05

Rules of engagement

Testing windows, rate limits, prohibited techniques, emergency contacts and how to stop the test.

06

Retest terms

How long you have to fix findings, how many retests are included and what evidence closes a finding.

06 · CHOOSING A PROVIDER

Eight Questions to Ask a Web App Pentest Provider

Ask for a redacted sample report before you sign. It answers half of these on its own.

01

Who will actually do the testing?

Ask for tester profiles and certifications, and whether the work is subcontracted.
02

How much is manual versus automated?

A report that reads like scanner output wasn't worth a pentest fee.
03

How do you test business logic?

Ask for examples from past reports. This is where providers differ most.
04

Can I see a redacted sample report?

Look for reproduction steps, real impact and specific fixes, not generic advice.
05

How is severity rated?

CVSS alone ignores context. Ask how they factor in exploitability and data exposure.
06

What's included in the retest?

One retest window is common; know how long it lasts and what it covers.
07

How do you handle production?

Expect written rules of engagement, rate limits and a stop procedure.
08

Can findings feed our tooling?

Exports to your tracker, and ideally to continuous testing, keep findings from going stale.
07 · STANDARDS & REQUIREMENTS

Web Application Pentest Standards and Compliance Drivers

The methodologies providers test against, and the requirements that usually trigger the engagement.

METHODOLOGY

OWASP Web Security Testing Guide (WSTG)

The most widely referenced test catalog for web applications, organized by category with test IDs.

RISK LIST

OWASP Top 10 (2021)

The ten most critical web application security risks, led by broken access control.

METHODOLOGY

PTES and NIST SP 800-115

General penetration testing frameworks covering planning, execution and reporting.

VERIFICATION

OWASP ASVS

Testable security requirements, useful for defining what "passed" means at each assurance level.

COMPLIANCE

PCI DSS v4.0

Requires regular penetration testing of in-scope applications and after significant changes.

ATTESTATION

SOC 2 and ISO/IEC 27001

Pentest reports are common evidence for vulnerability management and technical testing controls.

Summaries are for orientation only. Confirm specific requirements with your assessor.

08 · WHERE HAYROK FITS

Keep Pentest Findings True Between Engagements

Hayrok doesn't replace your pentesters. It turns their findings into scenarios that rerun on every release, validates the routine attack paths continuously, and hands the next engagement a validated starting point so human time goes to what only humans find.

01

Findings become scenarios

Import pentest findings; each becomes a scenario that reruns until the fix is proven.

02

Every release, every role

Authorization and known attack paths are validated as each role on every deploy.

03

Regressions caught early

A fixed finding that comes back opens as a validated finding, not a surprise next year.

04

A better next engagement

Testers start from a current, validated picture and spend their days on novel logic.

05

Evidence between reports

Evidence Fabric keeps replayable proof for auditors in the months between pentests.

09 · FAQ

Web Application Penetration Testing FAQ

An authorized, simulated attack on a web application by security testers, who try to find and exploit weaknesses in authentication, authorization, input handling, session management and business logic, then report what they could do and how to fix it.

BRING YOUR LAST REPORT

Find out which of your pentest findings are still true today.

Share a redacted pentest report and staging access. We'll turn the findings into scenarios, rerun them against today's build and show you what's fixed, what's back and what's new.