Web Application Security Testing Guide: WSTG, DAST and Manual Testing

Many web application security testing programmes scan the login page, get a clean report and miss the flaws that matter, because the scanner never authenticated, never saw the API behind the front end and cannot tell when one customer can read another customer's data. This guide covers how to test web applications and their APIs properly: the OWASP Web Security Testing Guide (WSTG) as the test catalogue, authenticated and multi-user DAST run continuously in CI/CD, and manual effort spent on business logic, authorisation and session management. It is for AppSec leads, test managers and engineering teams who own a web estate or commission a web app pentest. For the wider picture see the Penetration Testing Guide. Tool categories and the secure development lifecycle are covered in the Application Security Guide; this page stays on methodology, coverage and governance, with no attack payloads.

Key takeaways

• Use WSTG as the catalogue, not the plan. OWASP WSTG v4.2 groups 97 numbered test cases into 12 categories with stable IDs such as WSTG-SESS-01; choose the categories each application needs and record coverage by ID.
• Unauthenticated DAST is a perimeter check. Most attack surface sits behind login, so authenticated scanning with dedicated test accounts, session health checks and API definitions is the minimum for meaningful DAST coverage.
• Authorisation needs more than one user. Object and function level authorisation flaws only show up when you compare what two or more identities can reach, which is why multi user DAST and manual role matrices exist.
• Business logic is a human job. The WSTG states that business logic flaws "cannot be detected by a vulnerability scanner"; budget manual testing for workflows, payments, limits and approvals.
• PCI DSS changed the web app rule in 2025. Requirement 6.4.2 superseded the old "assess annually or deploy a protection layer" choice in 6.4.1 from 31 March 2025, while 11.4.1 still requires application-layer penetration testing.

What web application security testing covers

Web application security testing (web app security testing) verifies that a web application and the APIs it depends on enforce their security requirements under hostile use. It combines activities that are often confused:

• Web application vulnerability scanning (DAST scanning): automated crawling and probing of the running application over HTTP. Repeatable and cheap per run, weak on context.
• Web application penetration testing: a time-boxed, human-led web app pentest that chains weaknesses, tests authorisation and business rules and judges impact. Deep but periodic.
• Code-assisted testing: source review and SAST alongside dynamic testing, to confirm root causes and find flaws the running application does not reveal.
• Verification against requirements: checking against OWASP ASVS 5.0.0, which "provides a basis for testing application technical security controls."

No single activity is sufficient. The WSTG introduction says "a penetration test can only identify a small representative sample of all possible security risks in a system", that "automated black-box testing is not (nor will ever be) completely effective", and that "The correct approach is a balanced approach that includes several techniques." The UK NCSC adds the buyer's view: penetration testing should give assurance in your vulnerability management, "not as a primary method for identifying vulnerabilities", and "you should know what the penetration testers are going to find, before they find it."

The OWASP Web Security Testing Guide in practice

The OWASP Web Security Testing Guide is the de facto catalogue for web application testing, and the reference most providers use to describe web app testing scope. Version 4.2 is the current stable release and version 5.0 is in development, so cite v4.2 IDs in contracts and reports. The project calls itself "a complete testing framework, not merely a simple checklist". Test IDs take the form WSTG-<category>-<number>: WSTG-SESS-01 is "Testing for Session Management Schema" and WSTG-ATHZ-04 is "Testing for Insecure Direct Object References".

Two gaps matter. API testing in v4.2 has only a GraphQL case, so pair the WSTG with the OWASP API Security Top 10 2023 for REST APIs: API1:2023 Broken Object Level Authorization, API5:2023 Broken Function Level Authorization, API6:2023 Unrestricted Access to Sensitive Business Flows and API9:2023 Improper Inventory Management are the risks scanners handle worst. And the WSTG does not prioritise; deciding which tests apply to each application is what turns it into a web application security testing checklist you can run.

DAST that finds real issues: authentication, APIs and multiple users

DAST is black-box testing of the running application and needs no source code, which makes it the default for third-party and legacy applications. Results depend almost entirely on configuration. Treat these as minimum standards for any web vulnerability scanner you operate or buy.

Authenticated DAST

• Dedicated test identities: one test account per role per environment, never a real user or administrator. If an account can log in interactively, PCI DSS 11.3.1.2 expects it to be managed under Requirement 8.2.2.
• Login that survives the scan: configure logged-in and logged-out indicators and re-authentication. A scan that loses its session after five minutes reports clean on everything behind login.
• MFA and SSO: use a test tenant with a scripted login or short-lived pre-issued session tokens. Never weaken MFA in production to suit a scanner.
• Exclusions: keep logout, account deletion, password change and payment submission out of active scans.

API DAST

Crawlers find links, not the API operations a single-page application calls after a specific user action. Feed API DAST with the OpenAPI or GraphQL schema or recorded functional test traffic, with valid example values so requests reach business code, then compare the operations exercised with the API gateway's route list. The McKinsey AI platform hack turned on SQL injection in unauthenticated APIs, exactly the endpoints that drop out of testing when the inventory is incomplete. See the API Security Guide.

Multi user and context aware DAST

The WSTG says "The best way to test for direct object references would be by having at least two (often more) users". Multi user DAST automates this: it crawls as user A, replays the requests as user B and unauthenticated, and flags responses that should have been refused. Context aware DAST also tracks tenant, role and workflow step, so it can test function level authorisation and step skipping, not only injection. Both need a role matrix listing roles, the objects each may read or change, and expected responses; without it the scanner cannot tell a shared resource from a leak.

DAST vs pentesting, and where SAST fits

DAST vs pentesting is frequency against depth, not a choice of one. SAST and DAST complement each other the same way: SAST points to the line of code on every pull request, DAST proves exploitability in the deployed configuration.

• Choose DAST first for applications without source, for large estates where configuration drift is the main risk, and as a regression net for issues a pentest already found (SSDF PW.8.2 recommends keeping tests for previously reported vulnerabilities).
• Choose manual testing first for new applications that move money, hold regulated data, are multi-tenant or have complex authorisation.
• Small organisations: one authenticated DAST configuration per internet-facing application run weekly, plus an annual grey box test of the highest-risk application with retest.
• Large organisations: tier applications, require authenticated and API DAST in CI/CD for tiers 1 and 2, rotate manual providers and track WSTG category coverage per application.

For choosing scanners and providers see the Application Security Testing Buyer's Guide.

Continuous DAST in CI/CD

NIST SSDF task PW.8.2 asks teams to "Scope the testing, design the tests, perform the testing, and document the results", with dynamic vulnerability testing in the automated test suite as an example. Shift left DAST moves dynamic testing from a pre-release gate to the first environment where the application runs.

• Per pull request: a passive baseline pass against the preview environment covering configuration, headers, cookie attributes and error handling, finishing in minutes.
• Nightly: a full authenticated active scan with API definitions and multi-user replay, feeding the normal defect tracker.
• Per release: a gate that fails on new high or critical findings, with an exception route owned by the product owner.
• Continuous DAST in production: passive or explicitly safe checks only, under change control, from a test account and source address the SOC recognises. Active scans create records and trigger workflows.

Two points decide whether DAST in CI/CD survives. Test data: active scans need seeded accounts and objects that reset after each run. The protection layer: under PCI DSS 6.4.2 public-facing applications sit behind automated attack prevention, so scan the application origin in test to find code flaws, and separately confirm the production layer is blocking or alerting. A scan that only proves the WAF works says nothing about the application. See the Web Application Firewall Guide.

Manual testing: business logic, session management and authorisation

Aim manual effort where tools are blind. The WSTG notes that "Automated tools find it hard to understand context" and asks testers to "develop abused and misuse cases".

• Business logic testing: ask the business owner which rules the application must enforce (limits, approvals, pricing, eligibility) and turn each into a misuse case. Confirm multi-step workflows cannot be completed out of order, that server-side state decides price and eligibility, that one-time actions cannot be reused, and that uploads are validated.
• Session management testing: WSTG-SESS-01 asks testers to gather tokens for the same and different users and confirm "enough randomness exists to stop session forging attacks". Also check Secure, HttpOnly and SameSite on session cookies, a new session identifier at login and privilege change, server-side invalidation at logout and password reset, and timeouts that fit the risk. See the Token and Session Security Guide.
• Authorisation: test every sensitive operation as each role, as another tenant and unauthenticated, including the API calls behind the screens. Where the application fetches URLs server-side, include SSRF (WSTG 4.7.19); the Capital One breach showed how such a flaw can expose cloud role credentials.

Running the programme: rollout and reporting

1. Inventory and tier. List every web application and API with owner, exposure, data classification and authentication method. Testing cannot cover what the inventory omits.
2. Write a test standard per tier. State which WSTG categories and API Top 10 risks are covered, by which method and how often. This is your security testing checklist; version it.
3. Pilot authenticated DAST on two applications, one API-heavy and one legacy. Tune login handling, exclusions and API import until session health is stable for a week, and measure false positives.
4. Roll out by tier in rings. Tier 1 first, nightly, report-only for two to four weeks, then enable the release gate. If false positives block too many builds, roll the gate back to report-only and fix the configuration rather than disabling the scan.
5. Commission manual testing against the standard. Require findings mapped to WSTG IDs and, in PCI scope, to the attack types in Requirement 6.2.4. Supply role accounts and the role matrix. See the Penetration Test Scoping Checklist.
6. Report consistently. The WSTG reporting section suggests scope and limitations, an executive summary, a findings table, and per-finding reference ID, likelihood, impact, risk rating and remediation, on a scale such as Informational to Critical.
7. Close the loop. Retest every high and critical finding and add a regression test for each fix. The NCSC warns that vulnerability risk assessment "should not be wholly outsourced to the test team."

Where identity fits: scanner and tester credentials

Authenticated scanning means a scanner holds working credentials for every application it tests, often several roles each, and pipelines hold the secrets that start those scans. These are non-human identities with broad access. Keep them in a secrets manager rather than scan configuration files, scope each test account to one application and environment, rotate after each engagement, disable tester accounts the day testing ends, and alert on use outside scheduled windows. Error handling tests matter here too: the CrewAI error message flaw exposed an administrative token through an error response, the kind of leak WSTG-ERRH tests target. See the Secrets Management Guide.

Detection and measurement

Log scanner runs with source addresses, test account names and time windows so the SOC can tell an authorised scan from an attack, and spot test credentials used outside those windows. Track per tier:

• DAST coverage: share of inventoried internet-facing applications and APIs with an authenticated scan in the last 30 days.
• Session health: share of scans that stayed logged in throughout; below about 95 percent means silent blind spots.
• API operation coverage: operations exercised by DAST divided by operations published at the gateway.
• Manual coverage: share of tier 1 applications with ATHZ and BUSL manual testing in the last 12 months or since the last significant change.
• Time to remediate: median days from finding to verified fix, by severity, against SLA.
• Regression rate: share of closed findings that reappear.

Framework mapping

PCI SSC FAQ 1593 confirms 6.4.1 is superseded by 6.4.2 and should be marked Not Applicable after 31 March 2025. The option to review public-facing applications "at least once every 12 months and after significant changes" instead of deploying a protection layer is gone, but application-layer testing remains mandatory through 11.4.1. See the PCI DSS 4.0 Guide.

Common failure patterns

• Clean reports from logged-out scans. The scanner lost its session, so nothing behind login was tested. Report session health as a metric.
• Testing the screens, not the API. Operations no crawler finds go untested; the T-Mobile API breach shows how one abused API can expose tens of millions of records. Use schema-driven API DAST and gateway reconciliation.
• One user, one role. A single account cannot find IDOR or cross-tenant access. Test with at least two accounts per role.
• Treating the pentest as discovery. Testers keep finding the same injection and configuration issues and run out of time for logic and authorisation. Let DAST and SAST clear the basics first.
• Active scans against production. Scans that create orders or send emails get the programme switched off. Use production-like test environments.
• Findings without retests. Unverified fixes return two releases later. Retest and add a regression test before closing.

Practitioner checklist

• Maintain an inventory of web applications and APIs with owner, tier, exposure and authentication method.
• Publish a per-tier test standard mapping WSTG v4.2 categories and API Top 10 2023 risks to DAST, manual testing or both.
• Run authenticated DAST with dedicated per-role test accounts and check session health on every scan.
• Import OpenAPI or GraphQL schemas and reconcile scanned operations against the gateway route list.
• Use multi-user replay or manual role-matrix testing for every application with more than one role or tenant.
• Run a baseline DAST pass in pull requests and a full authenticated scan nightly in test.
• Commission manual testing focused on authorisation, business logic and session management, mapped to WSTG IDs.
• In PCI scope, confirm 6.4.2 protection is active and 11.4.1 testing covers the 6.2.4 attack types.
• Keep scanner and tester credentials in a secrets manager and revoke them when testing ends.
• Retest every high and critical finding and add a regression test before closing it.

Standards and references

• OWASP: Web Security Testing Guide
• OWASP: WSTG v4.2 Web Application Security Testing
• OWASP: Application Security Verification Standard
• OWASP: API Security Top 10 2023
• NIST: SP 800-218 Secure Software Development Framework
• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• PCI SSC: FAQ on superseded PCI DSS v4.x requirements after 31 March 2025
• NCSC: Penetration testing

Related NHI Mgmt Group resources: Penetration Testing Guide · Application Security Guide · API Security Guide · Web Application Attacks Guide · Application Security Testing Buyer's Guide