Framework

OWASP WSTG
Web Security Testing Guide, mapped to a single operating record

The OWASP Web Security Testing Guide (WSTG) is the consensus-driven manual for testing web applications. WSTG v4.2 is organised into 11 testing categories with hundreds of individual WSTG-IDs, each describing how to test for a specific class of weakness, what evidence to collect, and how to interpret the result. WSTG is the technique reference that pairs with ASVS as the verification standard, CVSS as the severity language, and OWASP Top 10 as the risk taxonomy. This page covers the 11 categories, the WSTG-ID structure, how WSTG sits next to ASVS, OWASP Top 10, PTES, NIST SP 800-115, and OSSTMM, the buyer-side reporting expectations, and the audit-grade evidence a WSTG-aligned engagement keeps in one operating record.

Get Started Free

No credit card required. Free plan available forever.

OWASP WSTG: the manual that says how to test, not what to worry about

The OWASP Web Security Testing Guide (WSTG) is the consensus-driven open manual for testing web applications. WSTG v4.2, the current stable release, is organised into 11 testing categories and several hundred individual tests, each with a stable WSTG-ID, an objective, a how-to, and notes on tooling. WSTG is the technique reference that pairs with the OWASP Top 10 as the risk taxonomy, with OWASP ASVS as the verification standard, and with CVSS as the severity language. Where the Top 10 answers what categories of risk matter, and ASVS answers what a verified-secure application looks like, WSTG answers how to actually test each weakness on the application in front of you.

WSTG matters to several audiences for different reasons. AppSec teams use WSTG as the in-house testing reference and the bar internal testing reads against. Product security teams cite WSTG-IDs when triaging scanner and bounty findings so each finding ties back to the test that produced it. Vulnerability management teams use WSTG categories to assess coverage gaps between scanners and manual testing. Penetration testing firms cite WSTG as the technique reference inside an engagement methodology declared as PTES or NIST SP 800-115. Security buyers read WSTG citations on proposals and reports to compare depth across providers. The page below walks through the categories, the WSTG-ID structure, and how WSTG sits next to OWASP Top 10, PTES, NIST SP 800-115, and OSSTMM.

The 11 WSTG testing categories

WSTG v4.2 organises web application testing into 11 categories. Each category contains individual tests identified by a stable WSTG-ID in the form CATEGORY-NN. A finding produced by a WSTG-aligned engagement cites the WSTG-ID, which is what makes the engagement record legible to engineering, auditors, and procurement reviewers alike. The category descriptions below are working summaries; the canonical text lives on the OWASP project page.

WSTG-INFO Information Gathering

Fingerprinting the application, the web server, the framework, and the deployment context. WSTG-INFO covers reconnaissance: search engine discovery, web server identification, application entry points, application architecture, comment and metadata leakage, and content discovery. The INFO phase produces the asset and surface map every subsequent category reads against, so an engagement that skips INFO produces narrower coverage than the asset list implies.

WSTG-CONF Configuration and Deployment Management

How the application is deployed and what configuration the operating environment exposes. CONF covers transport layer security (TLS settings, certificate handling, cipher suite selection), HTTP methods and security headers, file extensions and metafiles, admin interfaces, HTTP strict transport security, CDN and proxy headers, and infrastructure exposure. CONF findings cluster on the boundary between engineering and operations, which is why they read against both ASVS V14 (Configuration) and operating-side controls.

WSTG-IDNT Identity Management

Account provisioning, role definition, and the identifier lifecycle. IDNT covers role definitions, account enumeration through registration and password reset flows, weak identifier guessability, and account provisioning policy. The IDNT category is the bridge between the application and the identity provider; findings here often surface enumeration weaknesses that compound with authentication and authorization weaknesses elsewhere in the test plan.

WSTG-ATHN Authentication Testing

How the application proves who the user is. ATHN covers credential transport over an encrypted channel, default credentials, lockout against brute force, password change and recovery, browser cache weaknesses, weak password policy, weak security questions and answers, weak password reset, and multi-factor authentication. ATHN findings are high-density on most engagements and map cleanly to ASVS V2 and OWASP Top 10 A07.

WSTG-ATHZ Authorization Testing

What the application allows the authenticated user to do. ATHZ covers directory traversal and local file inclusion, privilege escalation (horizontal and vertical), insecure direct object reference, OAuth weaknesses, and JSON Web Token weaknesses. ATHZ is where most enterprise engagement effort concentrates because the findings are high-impact and the test cases require multiple authenticated personas to exercise correctly. ATHZ maps to ASVS V4 and OWASP Top 10 A01.

WSTG-SESS Session Management Testing

How the application binds the authenticated user to subsequent requests. SESS covers session schema attributes, cookie attributes (secure, HttpOnly, SameSite, expiration), session fixation, exposed session variables, cross-site request forgery, logout functionality, session timeout, session puzzling, and JWT session usage. SESS sits next to ATHN as the operational layer of authentication: weak sessions are how authentication weaknesses become exploitable, which is why SESS coverage is non-negotiable for an authenticated engagement.

WSTG-INPV Input Validation Testing

How the application validates and encodes user-controlled input. INPV is the broad surface that catches cross-site scripting (reflected, stored, DOM-based), HTTP verb tampering, HTTP parameter pollution, SQL injection, NoSQL injection, LDAP injection, XML injection and external entity, SSI injection, XPath injection, IMAP and SMTP injection, code injection, command injection, format string, incubated vulnerabilities, HTTP splitting and smuggling, server-side request forgery, and host header injection. INPV maps to ASVS V5 and OWASP Top 10 A03; volume here is high on most engagements.

WSTG-ERRH Error Handling

What the application discloses when something goes wrong. ERRH covers error message analysis and stack trace exposure. The category is small but load-bearing: error handling weaknesses are the entry point for reconnaissance against the rest of the application, and they compound with the INPV and ATHZ categories when verbose errors disclose schema or behaviour an attacker would otherwise have to infer.

WSTG-CRYP Cryptography

How the application protects data in transit and at rest. CRYP covers weak transport layer security, padding oracle weaknesses, sensitive information sent over unencrypted channels, and weak encryption. CRYP findings are often the technical foundation of a regulator-side audit citation; weak cryptography findings are the technical evidence behind PCI DSS Requirement 4, ISO 27001 Annex A.8.24, and HIPAA encryption rules.

WSTG-BUSL Business Logic Testing

How the application enforces business rules through workflows. BUSL covers business logic data validation, the ability to forge requests, integrity checks, process timing, function limits, circumvention of workflows, defences against application misuse, upload of unexpected file types and malicious files. BUSL is the category that resists automation hardest because the tests are workflow-aware rather than payload-aware; this is why mature engagements spend disproportionate effort here.

WSTG-CLNT Client-Side Testing

What happens in the browser. CLNT covers DOM-based cross-site scripting, JavaScript execution, HTML injection, client-side URL redirect, CSS injection, client-side resource manipulation, cross-origin resource sharing weaknesses, cross-site flashing, clickjacking, WebSocket weaknesses, web messaging weaknesses, browser storage weaknesses, and cross-site script inclusion. CLNT has grown in importance as single-page applications moved more of the application logic into the client, and is the category most likely to be under-tested by purely server-side scanners.

WSTG-APIT API Testing

How REST and GraphQL APIs hold up under direct testing. APIT was added in v4.2 to give APIs first-class treatment in the methodology. APIT pairs with the OWASP API Security Top 10 in scope-setting and reporting. Most modern web applications now include an API tier; an engagement scoped without APIT is an engagement that has not actually tested the application.

The category set is broad on purpose, so the categories in scope on a particular engagement are a deliberate choice rather than an assumed default. For a working checklist that maps category-level coverage onto the recurring engagement shape, see the web application penetration testing checklist and the matching web application testing use case.

WSTG-ID structure: stable citations for engineering and audit

Every WSTG test has a stable identifier in the form CATEGORY-NN. WSTG-ATHN-04 is the test for credential brute-force; WSTG-INPV-02 is the test for stored cross-site scripting; WSTG-ATHZ-04 is the test for insecure direct object references; WSTG-SESS-05 is the test for cross-site request forgery; WSTG-CRYP-01 is the test for transport layer security weaknesses; WSTG-BUSL-03 is the test for integrity checks; WSTG-CLNT-08 is the test for clickjacking. The identifier-first citation pattern is what lets the engagement record stay legible across the engineering, audit, and procurement audiences.

On a WSTG-aligned engagement, every finding cites the WSTG-ID that produced the evidence, the OWASP Top 10 risk category, the ASVS requirement number where the engagement is also verifying against ASVS, the CWE identifier, and the CVSS 3.1 vector. The citation pattern means the same finding can be read by a developer fixing the underlying weakness, by an auditor reviewing testing evidence for ISO 27001 Annex A.8.8 or PCI DSS Requirement 6 and 11.4, and by a procurement reviewer comparing reports across providers. The pattern is also what makes retest evidence durable: a retest scan that exercises WSTG-INPV-02 against the same asset can be paired back to the original finding without reinterpreting the test that produced it.

For the broader engagement scaffolding (scope, rules of engagement, authorisation, retest mechanics) that supports a WSTG-cited engagement, see the pentest rules of engagement template and the pentest scoping calculator.

How WSTG sits next to OWASP Top 10, ASVS, PTES, NIST SP 800-115, OSSTMM, MASTG, and scanners

WSTG is rarely cited alone. The working pattern is WSTG plus a verification standard (ASVS), plus a risk taxonomy (OWASP Top 10), plus an engagement methodology (PTES or NIST SP 800-115), plus a severity language (CVSS), with mobile and API surfaces declared separately (MASTG plus MASVS for mobile, API Security Top 10 plus WSTG-APIT for APIs). Buyer-side procurement reviewers and audit reviewers expect the citation set, not the single citation.

WSTG vs OWASP Top 10

OWASP Top 10 is the ranked list of the most critical risks to web applications, refreshed periodically from data submitted by hundreds of organisations. WSTG is the test procedure manual, much larger than the Top 10 and updated on its own cadence. The Top 10 answers "what risks should we worry about" and the WSTG answers "how do we test for each weakness." A finding written for a mature engagement cites both: the Top 10 category for the buyer narrative, and the WSTG-ID for the engineering record.

WSTG vs ASVS

OWASP ASVS is the verification standard that defines what a verified-secure application looks like, requirement by requirement, at three levels. WSTG is the technique reference that describes how to test for each weakness. ASVS answers "what do we verify" and WSTG answers "how do we verify it." Mature engagements declare an ASVS level for the scope, then list the WSTG categories and WSTG-IDs the verification reads against. Findings cite both the WSTG-ID and the ASVS requirement number.

WSTG vs PTES and NIST SP 800-115

PTES (Penetration Testing Execution Standard) and NIST SP 800-115 describe the engagement lifecycle: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, reporting. WSTG sits inside that lifecycle as the web testing reference for the vulnerability analysis and exploitation phases. Engagements typically declare PTES or NIST SP 800-115 as the engagement methodology and WSTG as the web testing technique reference, separately and explicitly.

WSTG vs OSSTMM

OSSTMM (Open Source Security Testing Methodology Manual) is a broader testing methodology covering data, communications, wireless, human, and physical security channels. WSTG is narrower and deeper: it covers the web application channel test by test. Engagements that include non-web channels (wireless, physical, social engineering) cite OSSTMM for those channels and WSTG for the web channel, with the engagement methodology naming both.

WSTG vs MASTG and OWASP API Security Top 10

MASTG (Mobile Application Security Testing Guide) is the mobile equivalent of WSTG, paired with MASVS as the verification standard. The OWASP API Security Top 10 is the API equivalent of the OWASP Top 10. An engagement that covers web, API, and mobile in one scope declares ASVS plus WSTG for the web tier, the API Security Top 10 plus WSTG-APIT for the API tier, and MASVS plus MASTG for the mobile tier separately. The three together produce a comparable depth claim across the surface.

WSTG vs scanner output

Scanner output is finding data, not a methodology. A scanner that fires the test cases for WSTG-INPV-05 (SQL injection) covers part of WSTG-INPV; the same scanner does not cover WSTG-BUSL (business logic) at all. The honest read of scanner output is to enumerate which WSTG categories the scanner can produce evidence for, which categories require manual testing, and which categories require both. The same enumeration is the basis for a defensible coverage statement at the end of an engagement.

Buyers comparing two web application engagement proposals should look at how each cites WSTG: a category-by-category coverage statement is a meaningful signal; a generic WSTG mention without category coverage is not. For a broader treatment of how to compare pentest proposals on depth, scope, retest, and reporting depth rather than headline price, see the pentest pricing models research and the pentest scope creep research. The pentest delivery gap research also covers the methodology mapping signal in some depth. For engagements that include a mobile tier alongside the web tier, the mobile side declares MASTG plus MASVS separately; the OWASP MASTG framework page covers the mobile-specific chapter map and the MASTG-TEST citation pattern that mirrors the WSTG-ID pattern on the web tier.

Reporting expectations for a WSTG-aligned engagement

A WSTG-aligned engagement report is a structured record, not a wrap-up document. The report is the artefact the buyer pays for, the assessor reviews, and the auditor cites, so its structure and the density of WSTG-ID citations determine whether the engagement was actually comparable to other WSTG-aligned work.

  • WSTG version declared up front (v4.2 at the time of writing), with any deviation from the stable version called out and justified
  • WSTG categories in scope listed at the engagement level, with explicit out-of-scope categories named so the buyer cannot misread coverage as broader than it was
  • Per-asset WSTG category scope where assets have different surfaces (a marketing site and an authenticated portal under the same domain have different reasonable test scopes)
  • Findings citing the WSTG-ID (for example, WSTG-ATHZ-04 for insecure direct object references), the ASVS requirement, the OWASP Top 10 category, the CWE identifier, and the CVSS 3.1 vector
  • Evidence retained on the finding record: the request, the response, the screenshot, the payload, or the proof-of-concept needed for a reviewer to validate the finding without asking for the working file
  • Coverage statement at the report level naming which WSTG categories were exercised, which were partially exercised, and which were not exercised, with a one-sentence reason per partial or excluded category
  • Retest scope agreed at kickoff and retest evidence per finding pointing back to the same WSTG-ID, so the verification report can include verified-fixed status without renegotiation
  • Closure record holding the original finding, the proposed fix, the retest evidence, and the final outcome, so the WSTG citation is a record rather than a frozen PDF

For a longer treatment of how to structure the report end to end, see how to write a pentest report and the matching penetration testing report template. The retest mechanics that hold up under a WSTG citation are covered in the retesting use case and the how to retest vulnerabilities guide.

How auditors and regulators read a WSTG citation

WSTG is not itself a regulator-issued standard; it is the open testing methodology that regulator-issued standards, certification schemes, and procurement frameworks accept as the technical reference for web application testing. The list below maps WSTG citations to the regulator-side and audit-side references that read against them; the same engagement record satisfies several reads at once when the citations are dense enough.

  • ISO 27001:2022 Annex A.8.8 (technical vulnerability management): WSTG citations are part of the technical testing evidence that supports the periodic vulnerability review the standard expects
  • ISO 27001:2022 Annex A.8.25 (secure development lifecycle): WSTG categories map to the testing stage of the SDLC, with WSTG-INFO and WSTG-CONF reading against deployment, WSTG-INPV reading against secure coding, and WSTG-BUSL reading against threat modelling
  • SOC 2 Trust Services Criteria CC7.1: WSTG-aligned engagements produce evidence of testing of system components for security weaknesses, with coverage statements that show the categories exercised
  • PCI DSS v4.0 Requirement 6.3.2 (identify vulnerabilities and assign a risk ranking): WSTG-ID citations and CVSS 3.1 vectors provide the technical reference and severity language the requirement reads against
  • PCI DSS v4.0 Requirement 11.4 (external and internal penetration testing): WSTG is one of the methodologies the requirement names, alongside NIST SP 800-115 and OSSTMM
  • NIST SP 800-53 Rev. 5 RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation): WSTG-aligned testing supplies the technical evidence the controls expect
  • NIST CSF 2.0 PR.PS (platform security) and DE.CM (continuous monitoring): WSTG-CONF and WSTG-CRYP evidence read directly against the platform security category, and the continuous monitoring category reads against the scheduled scanning that backs the manual testing
  • CREST OVS and CREST CHECK: CREST member firm reporting conventions cite WSTG by name as the technique reference inside the OVS or CHECK report
  • FedRAMP Penetration Test Guidance: the federal-side guidance cites WSTG as one of the methodologies acceptable for the web testing portion of an authorisation package
  • EU CRA Article 13 and CISA Secure by Design: while neither names WSTG directly, both expect documented testing methodologies and evidence; WSTG is the open reference programmes cite to satisfy that expectation

For the broader audit-evidence story (how the same finding can satisfy multiple reads without rebuilding the bundle for each audit), see the vulnerability evidence reuse across audits research and the audit evidence half-life research.

WSTG for AppSec teams, product security teams, vulnerability management, and pentest firms

WSTG reads differently depending on which side of the engagement you sit on. AppSec teams use WSTG as the in-house testing bar engineering builds against, and as the structure that triages findings from authenticated DAST, SAST, and SCA into one comparable picture. Product security teams cite WSTG-IDs when triaging bounty submissions and scanner findings so each finding ties back to the test that produced it. Vulnerability management teams use WSTG categories to identify coverage gaps between scanners and manual testing, and to decide where to spend manual testing budget. Pentest firms cite WSTG as the technique reference inside the engagement methodology, and as the language that lets buyers compare engagements over time.

The persona-specific entry points are SecPortal for application security teams, for product security teams, for vulnerability management teams, and for cybersecurity firms. Each anchors a different view of the same WSTG-cited engagement record.

Where SecPortal fits in a WSTG-aligned engagement

SecPortal is the operating record for a WSTG-aligned engagement. The platform handles scope, the WSTG categories and WSTG-IDs in scope per asset, the authentication context, finding triage, the WSTG-ID citation on every finding, the ASVS requirement mapping, the OWASP Top 10 category, the CVSS 3.1 vector, the evidence, the retest cycle, and the final deliverable, so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies and internal teams running WSTG-aligned engagements across a portfolio, the platform record supports multi-engagement reporting without re-tagging findings between engagements.

  • Engagement management captures the WSTG version, the categories in scope, the WSTG-IDs in scope per asset, the rules of engagement, the testing window, and the retest scope as a structured record so the methodology citation is the workflow rather than a contract attachment
  • Findings management stores each finding with a CVSS 3.1 vector, severity, evidence, owner, OWASP Top 10 category, CWE identifier, and a free-text mapping field for the WSTG-ID and the ASVS requirement, so the per-finding citation set is one record rather than a spreadsheet alongside the report
  • A library of over 300 finding templates accelerates evidence-density on common WSTG-IDs (XSS, SQL injection, IDOR, CSRF, weak TLS, missing security headers, weak password policy, OAuth and JWT weaknesses) so writeup time goes into the test that found the result rather than the boilerplate around it
  • Authenticated scanning runs DAST modules behind the login screen against the same engagement record, with credentials stored encrypted at rest under AES-256-GCM (cookie, bearer, basic, or form-login), so WSTG-IDNT, WSTG-ATHN, WSTG-ATHZ, WSTG-SESS, and WSTG-INPV evidence is reproducible across retest cycles
  • External scanning produces WSTG-CONF and WSTG-CRYP evidence (TLS configuration, HTTP security headers, exposed services, certificate handling, weak cipher suites) on a schedule, attached to the same engagement so transport and configuration claims are not re-tested manually for every report
  • Code scanning via Semgrep contributes SAST evidence on WSTG-INPV and WSTG-CRYP weaknesses that have a server-side root cause, with findings imported alongside the manual and DAST evidence on the same engagement record
  • AI report generation composes the executive summary, technical body, and remediation roadmap from the live engagement, findings, and WSTG coverage statement, citing the WSTG-IDs exercised rather than starting from a blank template
  • Retesting workflows pair each retest scan back to the original finding identifier and the original WSTG-ID, so the verified-fixed claim is auditable rather than asserted
  • Compliance tracking maps one WSTG-aligned engagement to ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS Requirement 6 and Requirement 11, NIST SP 800-53 RA-5 and SI-2, and the OWASP ASVS verification claim without rebuilding the bundle for each audit

For the end-to-end engagement workflow itself, see the penetration testing use case and the pentest project management use case. For scanner-side coverage interpretation against WSTG (which categories the scanner produces evidence for and which require manual testing), see the scanner coverage and limits guide and the scanner authentication failure modes guide.

For procurement-side context, including how to compare WSTG-aligned proposals on category coverage rather than headline price, see the pentest pricing models research, pentest delivery gap research, and severity calibration pentest findings research. For triaging scanner findings into WSTG-cited records, see the scanner result triage use case.

Key control areas

SecPortal helps you track and manage compliance across these domains.

WSTG v4.2: the testing manual, not the risk list

WSTG is the open OWASP manual that documents how to test a web application for security weaknesses. Where the OWASP Top 10 ranks the most critical risks and ASVS describes what a verified-secure application looks like requirement by requirement, WSTG covers the test procedures themselves. WSTG v4.2 (published in December 2020) is the current stable reference, organised into 11 testing categories and several hundred individual tests, each with a unique WSTG-ID, an objective, a how-to, and notes on tooling. Procurement frameworks, regulator guidance, and pentest reporting conventions cite WSTG by name when the question is which tests were run.

The 11 WSTG testing categories

WSTG v4.2 organises testing into 11 categories. WSTG-INFO covers Information Gathering (fingerprinting, content discovery, metafiles, reconnaissance). WSTG-CONF covers Configuration and Deployment Management Testing (TLS, HTTP methods, CDN, infrastructure). WSTG-IDNT covers Identity Management Testing (account provisioning, enumeration, registration). WSTG-ATHN covers Authentication Testing (credential transport, default credentials, lockout, MFA). WSTG-ATHZ covers Authorization Testing (directory traversal, privilege escalation, IDOR, OAuth and JWT). WSTG-SESS covers Session Management Testing (session attributes, fixation, CSRF, logout). WSTG-INPV covers Input Validation Testing (XSS, SQLi, SSRF, command injection, SSTI, deserialisation). WSTG-ERRH covers Error Handling. WSTG-CRYP covers Cryptography (transport, padding oracles, weak algorithms). WSTG-BUSL covers Business Logic Testing (workflow abuse, race conditions, replay, upload abuse). WSTG-CLNT covers Client-Side Testing (DOM-based XSS, postMessage, clickjacking, CORS, web storage). WSTG-APIT covers API Testing (REST and GraphQL specifics). The category prefix plus a numeric identifier (for example, WSTG-ATHN-04 for credential brute-force testing) is the citation format the engagement record reads against.

The WSTG-ID structure: citations engineering can read against

Every WSTG test has a stable identifier (CATEGORY-NN), an objective (what the test verifies), how-to-test steps, and a remediation pointer. The identifier is the unit a finding maps to: a finding for stored cross-site scripting cites WSTG-INPV-02; a finding for testing privilege escalation cites WSTG-ATHZ-03; a finding for testing logout functionality cites WSTG-SESS-06; a finding for testing for weak password reset cites WSTG-ATHN-09. The identifier-first citation pattern is what lets engineering read a finding against the test that produced it, what lets an auditor read a verification report against the methodology, and what lets a buyer compare two reports without re-reading the prose of every finding.

WSTG paired with ASVS, OWASP Top 10, and CVSS

WSTG is rarely cited alone. The mature pattern is WSTG for the technique (how the test was performed), ASVS for the requirement (what was verified), OWASP Top 10 for the risk taxonomy (what category of risk the finding belongs to), and CVSS for the severity (how serious the finding is). A finding written this way names the WSTG-ID that produced the evidence, the ASVS requirement the test satisfies or fails, the Top 10 risk category, the CWE identifier, and the CVSS 3.1 vector. The same finding then reads cleanly against ISO 27001 Annex A.8.8, SOC 2 CC7.1, PCI DSS 6.3.2 and 11.4, and a CREST OVS or ASVS verification report.

WSTG against PTES, NIST SP 800-115, and OSSTMM

PTES (Penetration Testing Execution Standard) describes the engagement lifecycle from pre-engagement to reporting. NIST SP 800-115 is the federal-side technical guide to security testing and assessment. OSSTMM is the Open Source Security Testing Methodology Manual. WSTG sits inside the lifecycle described by PTES and NIST SP 800-115, supplying the test-by-test depth for the web application portion. OSSTMM is the broader testing methodology covering channels beyond the web. Most enterprise engagements declare PTES or NIST SP 800-115 as the engagement methodology, then declare WSTG as the web testing technique reference. Mobile work declares MASTG separately; API work pairs WSTG-APIT with the OWASP API Security Top 10.

Reporting expectations for a WSTG-aligned engagement

A WSTG-aligned engagement report names the WSTG version (v4.2 at the time of writing), the categories in scope, the categories explicitly out of scope, and the asset and authentication context. Each finding cites the WSTG-ID, the ASVS requirement where applicable, the OWASP Top 10 category, the CWE identifier, the CVSS 3.1 vector, and the evidence (request, response, screenshot, payload, or proof-of-concept) retained on the finding record. The coverage section reads against the category list rather than the asset list, so the buyer can see which categories were exercised on which assets. Retest scope, retest evidence, and the closure record sit on the same engagement so the report is a structured record rather than a frozen PDF.

Buyer-side signals: how to read a WSTG citation

A WSTG citation on a procurement RFP, a vendor proposal, or a delivered report is a signal, not a proof. Strong WSTG alignment looks like a category-by-category coverage statement, finding citations naming WSTG-IDs rather than vague test descriptions, retest evidence pointing back to the original WSTG-ID, and a coverage gap statement explaining what was not tested and why. Weak alignment looks like a generic WSTG mention without category coverage, findings without WSTG-ID citations, and a coverage section that re-states the asset scope rather than the testing depth. The buyer-side read of a WSTG report is the depth of citation, not the existence of the citation.

Evidence the methodology expects to see

A WSTG-aligned engagement produces a stable evidence set as a side effect of the testing work. The category-and-test inventory captured during scoping (which WSTG categories and which individual WSTG-IDs are in scope), the authentication context per asset, the rules of engagement, the testing window, the per-finding WSTG-ID citation, the ASVS requirement mapping, the Top 10 category mapping, the CVSS vector, the CWE identifier, the evidence (request, response, screenshot, payload, proof-of-concept), the remediation guidance, the retest scope and the retest evidence per finding, the closure record, and the coverage statement that names categories and tests that were not exercised and why. The same artefact set reads against an ASVS verification claim, an ISO 27001 Annex A.8.8 audit, a SOC 2 CC7.1 audit, a PCI DSS 6.3.2 and 11.4 read, and a CREST OVS or buyer-side procurement review.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Compliance tracking without a full GRC platform

Hold the WSTG-aligned engagement on one workspace

Capture WSTG category scope, per-finding WSTG-ID citations, ASVS requirement mapping, OWASP Top 10 categorisation, CVSS 3.1 severity, evidence, retest scope, retest evidence, and the closure record on a single operating record alongside the authenticated DAST, external scanning, and code scanning evidence the SecPortal workspace already holds. Start free.

Get Started Free

No credit card required. Free plan available forever.