2.2 Target Selection and Assessment Types

Once agreements exist, you still have to point the test at the right objects. PT0-003 names four target-selection selectors: Classless Inter-Domain Routing (CIDR) ranges, domains, Internet Protocol (IP) addresses, and Uniform Resource Locator (URL). It then names seven assessment types: web, network, mobile, cloud, application programming interface (API), application, and wireless. Selectors answer where. Types answer what kind of test. Mixing them up — treating a URL as a /16, or treating cloud as whatever resolves on the internet — is how testers leave scope without noticing.

CIDR ranges and IP addresses

A CIDR range describes a block of addresses using a prefix length. 10.4.0.0/16 is 65,536 IPv4 addresses (10.4.0.0 through 10.4.255.255). 10.4.0.0/24 is 256 addresses. 10.4.12.8/32 is a single host. The exam loves off-by-one prefix mistakes: scanning 10.4.0.0/8 when the SoW said /16 jumps from 65,536 addresses to 16,777,216. That is not a rounding error; it is a different network, often including space the client does not route or own.

Cloud customers frequently believe they own a private range that is also used by a neighbor VPC, a shared services account, or a SaaS processor. Always reconcile CIDR with the exclusion list and with who actually routes those packets. DHCP and elastic public IPs mean yesterday's address may be someone else's tomorrow; RoE should say whether you re-verify ownership before each testing window.

IP addresses are the concrete hosts or interfaces. They may be IPv4 or IPv6. Ignoring IPv6 because the SoW printed only v4 is a real-world miss, not an excuse — dual-stack should be asked during scoping. A single IP in scope is not permission to hit its neighbors, its hypervisor, a NAT peer, or the management interface on the same blade.

Domains and URLs

Domains (DNS names such as example.com and app.example.com) identify naming scope, not automatically every host that answers on a name. A domain in scope usually includes agreed subdomains, but wildcard assumptions (*.example.com) must be written. Newly purchased lookalikes, forgotten development zones, and certificate-transparency names are research leads for later reconnaissance objectives; they are not in-scope targets until the SoW says so. Third-party domains that appear in HTML — status pages, CDNs, analytics, and payments.stripe.com-style processors — are not yours to attack just because they load on an in-scope page.

URLs pinpoint an application path, including scheme, host, port, and path: https://app.example.com/login. A URL in scope does not automatically include the entire origin, sibling paths, or the load balancer's management console. Conversely, a domain in scope does not automatically include every URL on a shared host, especially in multi-tenant SaaS. Write the intended meaning: the production web app at these URLs versus every service on this host. If checkout redirects to https://payments.example-processor.com, that origin is a different target until a separate authorization exists.

Assessment types

Official 1.1 assessment types are what you are testing, not how much the client told you in advance.

Web assessments target browser-facing applications: injection, authentication and authorization, session handling, XSS, CSRF, and business logic. They usually need named URLs, test accounts, and a WAF discussion in RoE (a production WAF may be in or out of scope as a control you are allowed to bypass).

Network assessments target hosts, routing, segmentation, exposed services, and often internal movement once a foothold exists. CIDR and IP lists dominate. Confirm whether you may cross from a user VLAN into OT/ICS, and whether discovery scans are limited to non-destructive intensities.

Mobile assessments target iOS/Android apps, sideloaded builds, the API backends the app calls, certificate pinning, local storage, and jailbreak or root assumptions. A store listing is not permission to test the production API. List the binary, OS versions, and backend URLs separately.

Cloud assessments target the customer's cloud configuration and workload: IAM policies, storage buckets, security groups, serverless functions, and Kubernetes clusters they own. The provider's physical data center, hypervisor, and managed-control-plane internals are normally out of scope. Check the cloud service provider's pentest terms of service before you scan.

API assessments target programmatic interfaces — REST, GraphQL, gRPC, SOAP — with attention to tokens, object-level authorization (BOLA/IDOR), rate limits, and schema abuse. An API can be in scope even when no browser UI is. A web test that never touches /api/v2 has often missed the real attack surface.

Application assessments cover software that is not only a website: thick clients, internal tools, installers, update channels, and local privilege boundaries. Scope the binary and its local resources explicitly.

Wireless assessments target Wi-Fi and sometimes Bluetooth or private radio. They need physical or RF authorization: which SSIDs, which sites, whether neighbors' networks must be ignored, and whether evil-twin or deauthentication is allowed. Hearing an SSID from the parking lot does not put it in scope.

Box colors are scoping language, not a substitute for types

PT0-003's numbered 1.1 list is assessment types, not box colors. In the field you will still see black box (no internal knowledge — outsider view), white box (credentials, source, architecture diagrams), and gray box (typical user or partial knowledge). Use them with a type: a gray-box web and API test of https://app.example.com, not black box as if that named the targets. Credentials, source access, and network location belong in the SoW; they do not expand CIDR, domain, IP, or URL lists by implication.

free PenTest+ practice questionsPractice questions with detailed explanations

Putting selectors and types together

Return to the Saturday SaaS SoW: 10.4.0.0/16, app.example.com, exclude the payment processor and production DB, 01:00–05:00. That is probably a web + API + network assessment of those selectors. It is not automatically a cloud assessment of the client's entire AWS organization, not a mobile test of the consumer iOS app, not a wireless test of headquarters, and not a license to follow redirects onto the processor. If the client also wants the iOS app and the object-storage buckets, those must be added as mobile and cloud targets with their own bundle IDs, account IDs, and URLs.

Exam trap: treating cloud as whatever has a public IP, or treating a single URL as permission to fuzz every hostname in certificate transparency logs. Name the type, name the selector, then test only that intersection.