Skip to content
Book a call

Home / Attacks & tests / Web Services Vulnerabilities

7 test cases

Web Services Vulnerabilities

Web services testing examines the application's programmatic surface: the endpoints built for other software rather than for a browser. They frequently predate the current interface, are documented in machine-readable form, and are protected on the assumption that only a trusted client will call them.

What an attacker is trying to achieve

The attacker prefers this surface. It is described by its own schema, it returns structured data rather than rendered pages, it often exposes operations the interface retired, and its authorisation is frequently coarser than the interface's.

Test cases

7 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-WSVC-01 Web Service Information Gathering

Objective — Establish the full inventory of programmatic endpoints, including versions and operations the current client no longer calls.

How it is tested — Retrieve every published schema, specification and discovery document, and compare what they describe against what the client actually uses. Probe for alternative version prefixes and for documentation interfaces served alongside the service. Extract endpoints referenced only in client bundles or mobile applications. Record for each operation the methods, parameters and authentication it expects.

Prerequisites — The application and any mobile client; the client bundles; permission to request undocumented paths.

Indicators — A schema published without authentication; a previous API version still served; a documentation or exploration interface reachable; operations described that the interface never calls.

CoverageWSTG-APIT-01WSTG-INFO-04CWE-200

DepthHybrid Schema retrieval automates; recovering endpoints from a mobile client or a minified bundle does not.

WEB-WSVC-02 Service Definition Weaknesses

Objective — Determine whether the service's own definition document exposes more than intended, or describes constraints the implementation does not enforce.

How it is tested — Retrieve the definition and enumerate every operation, type and constraint it declares. Establish whether it is reachable without authentication and whether it names internal hosts, deprecated operations or administrative functions. Then test whether the constraints it declares — types, lengths, enumerations, required fields — are enforced by the implementation, by submitting values the definition forbids.

Prerequisites — The definition document; a client able to submit requests that violate it; a non-production environment.

Indicators — A definition reachable unauthenticated; internal hosts or administrative operations described; a declared constraint not enforced at runtime; operations present in the implementation but absent from the definition.

CoverageWSTG-APIT-01V13.1.3V5.1.4CWE-200CWE-20

DepthHybrid Enumeration automates; the interesting result is the gap between what is declared and what is enforced.

WEB-WSVC-03 Weak XML Structure

Objective — Determine whether the service's parser accepts documents that are structurally hostile rather than merely invalid.

How it is tested — Submit documents that are well-formed but abusive: deeply nested elements, very large attribute counts, entity declarations that expand recursively, and references to external resources. Observe whether the parser bounds depth and expansion, and whether external resolution is disabled. Test whether schema validation occurs before processing or after, since a parser that expands entities before validating gains nothing from the schema.

Prerequisites — An endpoint accepting XML; a non-production environment; explicit permission, since expansion tests consume resources; a listener for external resolution.

Indicators — Recursive entity expansion consuming memory; external references resolved; no depth or size bound; validation applied after expansion.

CoverageWSTG-INPV-07V13.3.1V5.5.2CWE-776CWE-611

DepthHybrid Standard payloads automate; distinguishing where validation sits relative to expansion requires interpretation.

WEB-WSVC-04 XML Content-Level Attacks

Objective — Determine whether values carried inside a structurally valid document reach interpreters unsafely, the document having satisfied schema validation.

How it is tested — Place injection payloads for each downstream interpreter — database, directory, command, expression language — inside element and attribute values that conform to the declared types. Where the schema constrains a type, use a payload that satisfies it. Test values that are used as identifiers or references within the service, and any element whose content is later rendered.

Prerequisites — The definition, to construct conformant documents; a non-production environment; knowledge of the downstream components from architecture mapping.

Indicators — A conformant document producing a downstream injection; schema validation passing while the value reaches an interpreter; a value rendered unescaped by a consumer of the response.

CoverageWSTG-INPV-07V13.3.1V5.3.4CWE-91CWE-89

DepthManual Payloads must satisfy the schema and still be hostile, which requires reading the schema.

WEB-WSVC-05 REST and Query Parameter Handling

Objective — Determine whether operations exposed over simple parameters enforce the same authentication, authorisation and method constraints as the rest of the service.

How it is tested — For each operation, attempt invocation with parameters moved between query string, body and headers, and with methods other than the documented one. Establish whether state-changing operations are reachable by a read method, which would make them reachable by a simple link. Test object references across accounts, and whether filtering, ordering and expansion parameters widen what is returned beyond the caller's entitlement.

Prerequisites — Two accounts in different ownership scopes; the operation inventory; a client able to vary method and parameter placement.

Indicators — A state-changing operation reachable by a read method; parameters honoured from an unexpected location; another account's object returned; an expansion parameter widening the response beyond entitlement.

CoverageWSTG-APIT-02V13.2.1V4.2.1CWE-639CWE-650

DepthManual The object-reference and expansion cases need two ownership scopes and knowledge of what each should see.

WEB-WSVC-06 Malicious Attachments and Payloads

Objective — Determine how the service handles attached content, and whether attaching a file bypasses the checks applied to uploads through the interface.

How it is tested — Submit attachments whose declared type disagrees with their content, attachments far larger than expected, and content types the service does not document. Establish whether the same size, type and content checks applied to interface uploads apply here. Test whether attached documents are parsed server-side, and whether structured attachments can carry the external-reference and expansion payloads tested elsewhere.

Prerequisites — An operation accepting attachments; a non-production environment; the interface's upload behaviour established first for comparison.

Indicators — Checks weaker than the interface's for the same content; an attachment parsed server-side without constraint; a mismatched declared type accepted; no size ceiling.

CoverageWSTG-BUSL-09V12.2.1V13.1.5CWE-434CWE-20

DepthHybrid Submission automates; the finding is usually the difference between two paths, which requires testing both.

WEB-WSVC-07 Web Service Replay Testing

Objective — Determine whether a captured service request can be resubmitted and honoured, by the original caller or by another, and whether it remains valid indefinitely.

How it is tested — Capture authenticated service requests and resubmit them unchanged, then after the session has ended, then from a different source. Where a signature, timestamp or nonce is present, establish whether it is verified, whether the timestamp window is bounded, and whether the nonce is recorded as used. Repeat concurrently to determine whether uniqueness is enforced transactionally or only by ordering.

Prerequisites — Captured authenticated service requests; a non-production environment; the ability to submit concurrent duplicates from more than one source.

Indicators — A captured request honoured after its session ended; a nonce accepted twice; no timestamp window; concurrent duplicates both succeeding; a signature not verified.

CoverageWSTG-SESS-09V13.2.6CWE-294CWE-345

DepthManual Requires holding a request across a session boundary and replaying it deliberately.

What we need from you

Any schema, specification or collection describing the service, which should be requested before the engagement rather than reconstructed; credentials for each consumer type including any machine account; and a non-production environment, since programmatic endpoints act at volume.

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-APIT-01 — API Reconnaissance
  • WSTG-INFO-04 — Enumerate Applications on Webserver
  • CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
  • V13.1.3 — Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
  • V5.1.4 — Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).
  • CWE-20 — Improper Input Validation
  • WSTG-INPV-07 — Testing for XML Injection
  • V13.3.1 — Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.
  • V5.5.2 — Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
  • CWE-776 — Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
  • CWE-611 — Improper Restriction of XML External Entity Reference
  • V5.3.4 — Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.
  • CWE-91 — XML Injection (aka Blind XPath Injection)
  • CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
  • WSTG-APIT-02 — API Broken Object Level Authorization
  • V13.2.1 — Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.
  • V4.2.1 — Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
  • CWE-639 — Authorization Bypass Through User-Controlled Key
  • CWE-650 — Trusting HTTP Permission Methods on the Server Side
  • WSTG-BUSL-09 — Test Upload of Malicious Files
  • V12.2.1 — Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.
  • V13.1.5 — Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).
  • CWE-434 — Unrestricted Upload of File with Dangerous Type
  • WSTG-SESS-09 — Testing for Session Hijacking
  • V13.2.6 — Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.
  • CWE-294 — Authentication Bypass by Capture-replay
  • CWE-345 — Insufficient Verification of Data Authenticity

Tell us what the system does and what worries you.

If a penetration test is not what you need yet, we will say so.

Book a scoping callSee the test catalogue