PT0-002 Practice Question: A client wants to test a web application that…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The tester must use only non-intrusive scanning techniques on the APIs.

  Why this is correct

  Non-intrusive scanning techniques—such as passive traffic analysis, carefully rate-limited read-only GET requests, and benign parameter fuzzing that avoids destructive payloads—are essential when testing third-party APIs because aggressive testing could trigger rate limiting, WAF blocks, or even degrade the shared API infrastructure that other applications depend on. This approach preserves the availability of the target application and its dependencies while still allowing the tester to identify misconfigurations, broken authentication, or improper error handling. Non-intrusive methods also reduce the chance of committing to an expensive or legally problematic action, especially when the API provider is not directly part of the tested scope.

• ✗

  The tester must exclude all API endpoints from testing.

  Why it's wrong here

  Excluding all API endpoints from the test scope creates a false sense of security because the web application's integration layer remains a prime attack surface—vulnerabilities such as IDOR, mass assignment, or improper handling of API responses can be exploited without ever directly attacking the third-party server. If the tester ignores these endpoints, they will miss issues like insecure direct object references in the client-side code that fetches user data from the API, or business logic flaws that arise from crafted API responses. The goal is to assess the application's security, and the API is often a crucial part of that attack surface, so a blanket exclusion is both unsafe and inconsistent with a thorough penetration test.

• ✗

  The tester must coordinate testing schedules with the API vendors.

  Why it's wrong here

  While coordinating schedules with API vendors may be academically useful for tests that might cause a denial of service, it is not a necessary prerequisite for a penetration test targeting the web application because the tester's responsibility is to ensure that their methods are non-intrusive and respect rate limits, not to obtain advance approval from every third party. In practice, many third-party APIs are public and the tester has no existing relationship with the vendor, and attempting to coordinate with multiple vendors could seriously delay the engagement and may even be prohibited by the vendor's terms. Furthermore, the primary risk of disruption is to the client's own services, and non-intrusive techniques already mitigate that risk, making vendor coordination a helpful but non-essential step.

• ✗

  The tester must provide a list of all API calls to be made prior to testing.

  Why it's wrong here

  Providing an exhaustive list of all API calls before testing is a procedural formality that might be included in a rules-of-engagement document, but it does nothing to reduce operational risk because a tester can still execute a request list with high volume, malformed payloads, or concurrent requests that cause harm. Modern dynamic testing often requires an iterative and adaptive approach, where the tester discovers new endpoints and parameters during the assessment, making it impossible to pre-enumerate every call in advance. The true safeguard is the choice of non-intrusive techniques and controlled request rates, not the documentation of intended calls, so this option addresses a different concern than the operational risk described in the question.

Go deeper

Related to this question