Information gathering establishes what the application actually is before any attempt is made to break it: which technologies serve it, which entry points exist, and what the organisation has published about it without meaning to. It is the phase that decides whether the rest of the test is aimed at the real attack surface or only at the part that is easy to find.

What an attacker is trying to achieve

The attacker wants the map the defender has, and preferably the parts of it the defender has forgotten — a staging host, a retired API version, a framework whose version has a public exploit. Nothing at this stage is itself a breach, which is why it is often left undone; every later phase is narrower and less complete when it is.

Test cases

10 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.

WEB-INFO-01 Search Engine Discovery and Reconnaissance

Objective — Determine what the application and its organisation have exposed through third parties — search indexes, code hosts, package registries and paste sites — that narrows an attacker’s work before a single request reaches the application.

How it is tested — Query the major search indexes with operators restricting results to the in-scope domains, looking for administrative paths, backup and archive extensions, configuration files and error pages. Search public code hosting for the organisation’s domains, internal hostnames and API key formats. Check package registries for internally-named packages, and certificate transparency logs for hostnames that were never meant to be public. Repeat against cached copies, which retain content after it is removed from the live site.

Prerequisites — The in-scope domain list; the organisation’s name variants and any acquired brands; no access to the application itself is required.

Indicators — An indexed administrative interface, a credential or key in a public repository, an internal hostname in a certificate log, or a cached page containing content the live site no longer serves.

Coverage — WSTG-INFO-01CWE-200

Depth — Hybrid Index queries and certificate-log enumeration are automated; judging whether a disclosed item matters is not.

WEB-INFO-02 Web Server Fingerprinting

Objective — Identify the server software, version and intermediary chain handling requests, since the defect classes worth testing for and the exploits already published depend on exactly that.

How it is tested — Compare response headers, header ordering and default error pages against known signatures. Issue deliberately malformed requests — unknown methods, invalid versions, oversized headers — because servers differ more in how they reject input than in how they accept it. Observe redirect behaviour, supported protocol versions and TLS stack characteristics. Where a CDN or reverse proxy answers, work to identify the origin behind it rather than reporting the edge.

Prerequisites — Direct HTTP access to the application; the ability to send non-conforming requests, which some proxies normalise away.

Indicators — A server and version disclosed in headers or an error page; behaviour matching a known signature; an origin server reachable directly, bypassing the edge protections in front of it.

Coverage — WSTG-INFO-02CWE-200

Depth — Hybrid Signature matching is automated. Reaching a hidden origin, and reading behavioural rather than header evidence, is manual.

WEB-INFO-03 Webpage Comments, Metadata and Metafiles

Objective — Determine what the application discloses in content that is served but not displayed — comments, source maps, metadata and files intended to instruct crawlers rather than to be read by them.

How it is tested — Retrieve and review page source, JavaScript bundles and their source maps, stylesheets, and document metadata for developer comments, internal hostnames, disabled features, credentials and account names. Fetch the crawler metafiles and treat their exclusion lists as an index of paths the organisation considers sensitive. Examine uploaded office documents and images for retained authorship, path and revision metadata.

Prerequisites — Unauthenticated access to the application’s public pages and static assets; a copy of any downloadable document the application publishes.

Indicators — A credential, internal hostname or unreleased feature named in a comment; a source map exposing original server-adjacent code; an exclusion entry pointing at an administrative path; authorship metadata in a published document.

Coverage — WSTG-INFO-03WSTG-INFO-05CWE-615CWE-200

Depth — Hybrid Retrieval and pattern matching are automated; recognising that an innocuous-looking string is an internal identifier is not.

WEB-INFO-04 Application Entry Point Identification

Objective — Establish the complete set of points at which the application accepts input, so that later phases test the whole surface rather than the portion reachable by clicking through the interface.

How it is tested — Browse the application in full with a proxy recording every request, then extract from it each parameter, header, cookie and body field the application reads. Supplement with routes referenced only in client-side code, in API schema documents, and in requests the interface issues conditionally. Record for each entry point the methods accepted, whether authentication is required, and which role reaches it.

Prerequisites — An account for each role; an intercepting proxy; any API schema or collection the development team can supply, which shortens this considerably and is worth asking for before the engagement starts.

Indicators — Entry points not reachable through the interface; parameters accepted but undocumented; methods accepted beyond those the interface uses; routes surviving from a previous API version.

Coverage — WSTG-INFO-06CWE-1059

Depth — Hybrid Proxy capture and parameter extraction are automated; recovering routes referenced only in minified client code is manual.

WEB-INFO-05 Execution Path Mapping

Objective — Determine which paths through the application are actually reachable and in what order, so coverage can be measured against the application’s real structure rather than against a list of URLs.

How it is tested — Exercise each workflow end to end and record the sequence of requests and state changes it produces. Identify branch points where the application chooses between paths, and the conditions governing them. Compare the paths reachable through the interface with those the routing layer defines, and note any function that exists but is never linked. Record which paths change state and which only read, since that distinction drives how later tests may safely be run.

Prerequisites — Accounts for each role; a test environment where state-changing workflows may be completed; a proxy recording the full session.

Indicators — Reachable functions absent from the interface; workflows completing when steps are skipped; branch conditions decided on the client; routes defined but undocumented.

Coverage — WSTG-INFO-07CWE-1059

Depth — Manual A crawler records URLs, not workflows. Understanding which order of requests constitutes a path is human work.

WEB-INFO-06 Framework Fingerprinting

Objective — Identify the application framework and its version, which determines the default routes, debug facilities, template syntax and known defect classes worth testing for.

How it is tested — Look for framework-specific cookie names, header values, static asset paths, error page structure and template artefacts. Request paths that exist only in particular frameworks — default consoles, health endpoints, debug toolbars — and compare responses for existing versus absent paths. Where a framework version can be narrowed, check whether facilities that ship enabled by default in that version are still reachable in this deployment.

Prerequisites — HTTP access; the ability to request arbitrary paths, including ones the interface never links.

Indicators — A framework-specific cookie, header or asset path; a default console or debug endpoint reachable; an error page identifying the framework and its version.

Coverage — WSTG-INFO-08CWE-200

Depth — Hybrid Signature matching is automated; confirming that a default facility is genuinely reachable rather than merely referenced requires a manual check.

WEB-INFO-07 Application Fingerprinting

Objective — Identify the application itself where it is a known product or a known product’s derivative, since a version number then implies a published defect list that no amount of black-box probing would otherwise reveal.

How it is tested — Compare static assets, favicon and icon hashes, distinctive markup and administrative paths against signatures for known products. Where the product is identified, determine the version from asset hashes, changelog or manifest files, and version-specific behaviour rather than from a banner, which is easily altered. Where the application is a customised instance, establish which parts remain stock, since those are the parts public exploits target.

Prerequisites — HTTP access to static assets; no authentication required for most of it.

Indicators — An asset hash matching a known release; a version-bearing manifest served publicly; stock administrative paths present in a customised deployment.

Coverage — WSTG-INFO-09CWE-1395

Depth — Hybrid Hash comparison is automated; distinguishing a customised component from a stock one is a judgement.

WEB-INFO-08 Application Architecture Mapping

Objective — Establish the components between the client and the data — edge proxies, load balancers, application servers, caches, and the services behind them — because a control enforced at one layer is often absent at the next.

How it is tested — Infer topology from response headers, caching behaviour, timing differences and error messages originating at different layers. Compare how equivalent requests are handled through different hostnames or paths. Identify caches by observing whether responses vary per session, and identify separate backends by inconsistencies in header ordering or error format. Establish whether any component can be addressed directly, bypassing the layers in front of it.

Prerequisites — HTTP access; the ability to send requests that will be rejected, since rejection paths reveal layering more clearly than success paths.

Indicators — Distinct error formats implying separate backends; a cache serving one session’s response to another; a backend reachable directly; a security header present on one path and absent on another.

Coverage — WSTG-INFO-10WSTG-CONF-01CWE-200

Depth — Manual Inferring architecture from behavioural differences is interpretation, not signature matching.

WEB-INFO-09 Information Disclosure Through Error Codes

Objective — Determine what the application reveals about its internals when a request fails, and whether the difference between failure modes itself discloses information the caller should not have.

How it is tested — Submit input designed to fail at different layers — malformed syntax, type mismatches, absent required fields, references to non-existent and to existing-but-unauthorised objects — and compare the responses. Record status code, body, headers and timing for each. Pay particular attention to whether a request for an object that does not exist is distinguishable from one for an object that exists but belongs to another principal, since that difference enumerates data.

Prerequisites — Two accounts in different ownership scopes so existence and authorisation failures can be compared; a proxy.

Indicators — A stack trace, query fragment, internal path or component version in a response; a measurable difference between not-found and not-permitted; verbose failures on one entry point where others are terse.

Coverage — WSTG-ERRH-01CWE-209CWE-203

Depth — Hybrid Scanners find verbose stack traces. The distinguishable-failure case needs a deliberate comparison a scanner does not set up.

WEB-INFO-10 SSL/TLS Configuration Review

Objective — Establish which protocol versions, cipher suites, key sizes and certificate properties the application’s transport layer accepts, and whether any of them are below current guidance.

How it is tested — Enumerate the protocol versions and cipher suites the endpoint negotiates, including for hostnames and ports serving the same application indirectly. Examine the certificate chain for validity dates, key size, signature algorithm, name coverage and trust path. Check whether downgrade is possible, whether renegotiation is permitted, and whether the same configuration holds across every in-scope host rather than only the primary one.

Prerequisites — Network reachability to each in-scope host and port; the full hostname list, since weaker configurations usually live on the secondary names.

Indicators — A deprecated protocol version negotiated; a cipher suite without forward secrecy; a certificate expiring, self-signed, or not covering the name in use; a host in scope configured more weakly than the primary.

Coverage — WSTG-CRYP-01V9.1.2CWE-326CWE-327

Depth — Automated Enumeration is reliably automated. The manual contribution is ensuring every in-scope host is tested, not only the obvious one.

What we need from you

The application reachable from the testing source address, with any WAF or rate limit either lifted for the test window or documented so its effects can be distinguished from the application’s own behaviour; the in-scope hostnames and IP ranges stated in writing, since reconnaissance naturally drifts toward assets that were never in scope.

Standards this category maps to

Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.

  • WSTG-INFO-01 — Conduct Search Engine Discovery and Reconnaissance for Information Leakage
  • CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
  • WSTG-INFO-02 — Fingerprint Web Server
  • WSTG-INFO-03 — Review Webserver Metafiles for Information Leakage
  • WSTG-INFO-05 — Review Webpage Content for Information Leakage
  • CWE-615 — Inclusion of Sensitive Information in Source Code Comments
  • WSTG-INFO-06 — Identify Application Entry Points
  • CWE-1059 — Insufficient Technical Documentation
  • WSTG-INFO-07 — Map Execution Paths Through Application
  • WSTG-INFO-08 — Fingerprint Web Application Framework
  • WSTG-INFO-09 — Fingerprint Web Application
  • CWE-1395 — Dependency on Vulnerable Third-Party Component
  • WSTG-INFO-10 — Map Application Architecture
  • WSTG-CONF-01 — Test Network Infrastructure Configuration
  • WSTG-ERRH-01 — Testing for Improper Error Handling
  • CWE-209 — Generation of Error Message Containing Sensitive Information
  • CWE-203 — Observable Discrepancy
  • WSTG-CRYP-01 — Testing for Weak Transport Layer Security
  • V9.1.2 — Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.
  • CWE-326 — Inadequate Encryption Strength
  • CWE-327 — Use of a Broken or Risky Cryptographic Algorithm