Overview
The targets section of the rules of engagement lists exactly which systems are authorized for testing. Getting the target list right is the foundation of a safe, legal engagement. This lesson covers defining targets.
Learning objectives
- Explain how targets are specified in an ROE.
- Describe precise target identification.
- Connect clear targets to legal, focused testing.
Core concept
Targets are the specific, authorized systems in scope — identified precisely by domains, IP addresses/ranges, application URLs, or asset identifiers, along with the relevant environment (e.g. production vs staging). Precision matters: vague targets ("the website") invite ambiguity, while precise ones ("app.example.com and its API at api.example.com, staging environment") leave no doubt about what is authorized. The target list, agreed in writing, is the concrete set the tester may act against.
How it works
Before testing, the owner and tester agree an explicit target list. The tester acts only against those identified targets. Precise identification avoids accidentally testing the wrong asset — for instance, a similarly named system, a shared-hosting neighbor, or a third-party service. Where targets are specified by IP range or domain, the tester confirms the boundaries and verifies that in-practice resolution (e.g. what a domain points to) stays within authorization. Clear targets keep testing legal and prevent collateral impact on unauthorized systems.
Practical example
An ROE lists targets as app.example.com, api.example.com, and a specific staging IP range, all in the staging environment. The tester verifies these resolve to the intended, authorized systems and tests only them. A visually similar domain, or an IP just outside the listed range, is not a target and is left alone. The precise target list is the authority for exactly which systems may be touched.
Cybersecurity relevance
Precise target definition is essential to legality and safety: testing the wrong system — even by accident — is unauthorized access and can cause harm or legal liability. Ambiguous targets are a real risk (e.g. shared hosting where an IP hosts multiple owners' sites). Verifying that targets resolve to authorized systems, and testing strictly within the list, is professional discipline. Clear targets, combined with exclusions (next lesson), keep the engagement bounded and lawful.
Common mistakes
- Vague target definitions that leave authorization ambiguous.
- Testing a similar-but-different asset (look-alike domain, adjacent IP, shared-hosting neighbor).
- Not verifying that a domain/IP resolves to the authorized system before testing.
Key takeaways
- Targets are the precisely identified, authorized systems (domains, IPs/ranges, application URLs, environment) the tester may act against.
- Precision prevents accidentally testing the wrong asset; verify targets resolve to the intended authorized systems.
- A clear target list keeps testing legal and focused and works with exclusions to bound the engagement.
Check your understanding
- Why must targets be defined precisely rather than vaguely?
- What risk arises on shared hosting or with look-alike domains, and how does precise targeting address it?