Targets

What Is a Target?

A target is a specific URL that you want TurboPentest to pentest. While domain verification establishes authorization over an entire domain tree, targets specify the exact entry points where the pentest begins. Think of domain verification as permission and targets as the actual addresses you want tested.

Every target must belong to a verified domain. If you have verified example.com, you can add targets like https://app.example.com, https://api.example.com/v2, or https://staging.example.com. You cannot add a target under a domain that has not been verified.

Target URL Structure

A target URL tells TurboPentest where to begin its testing. The URL includes several components that affect how the pentest is conducted:

Protocol — TurboPentest supports both https:// and http:// targets. HTTPS targets are strongly recommended for production testing. If you specify an HTTP target, TurboPentest will test it over HTTP but will also check for HTTPS availability and report missing TLS as a finding.

Hostname — The domain or subdomain to test. This must fall under a verified root domain. You can target the root domain itself (https://example.com) or any subdomain (https://api.example.com).

Port — If your application runs on a non-standard port, include it in the URL (e.g., https://app.example.com:8443). If omitted, TurboPentest assumes the default port for the protocol (443 for HTTPS, 80 for HTTP).

Path — You can optionally include a path to scope the pentest to a specific section of your application (e.g., https://app.example.com/admin). When a path is included, the pentest begins its crawl and analysis from that path rather than the root. This is useful for large applications where you want to focus testing on a specific area.

Adding Targets

You can add targets from the TurboPentest dashboard or via the API.

From the dashboard: Navigate to your domain's page, click "Add Target," and enter the full URL. The platform validates that the URL belongs to a verified domain before accepting it.

From the API:

curl -X POST https://turbopentest.com/api/pentests \
  -H "X-API-Key: $TURBOPENTEST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "targetUrl": "https://app.example.com",
    "repoUrl": "https://github.com/org/repo"
  }'

The targetUrl field is required. The repoUrl field is optional and enables white-box testing by connecting a GitHub repository for static code analysis.

Target Scope and Crawler Behavior

When a pentest starts, TurboPentest's tools and agents use the target URL as the starting point. Phase 1 tools like Subfinder will discover additional subdomains under the verified domain, and tools like FFUF will enumerate directories and paths beyond the target URL. The target URL is the entry point, not a hard boundary.

However, all testing stays within the verified domain tree. If agents discover links to external domains during crawling, they will not follow them or test those external domains. The verification boundary is enforced at every level of the testing pipeline.

This behavior means you should think of your target URL as a starting point for discovery rather than a strict perimeter. If your application at https://app.example.com links to https://api.example.com, both will be tested (assuming both are under the verified example.com domain). But a link to https://third-party-cdn.com would not be followed.

Managing Multiple Targets

Most organizations have more than one application to test. TurboPentest makes it easy to manage multiple targets:

• Multiple targets per domain — Add as many targets as you need under a single verified domain. Each target can be pentested independently with its own schedule and tier.
• Different configurations per target — One target might be tested weekly with Standard tier while another is tested monthly with Deep tier. Target configurations are independent.
• Target notes — Add optional notes to each target to help your team remember context, such as "Production API - test after each sprint release" or "Staging environment - safe for aggressive testing."

Best Practices for Target Configuration

Start with your most critical application as your first target. This is typically your production web application or customer-facing API. Use HTTPS URLs for production targets. Include path prefixes only when you need to focus testing on a specific area — otherwise, start from the root to get the broadest coverage.

For applications with separate frontend and backend services (e.g., app.example.com for the frontend and api.example.com for the API), consider adding both as separate targets. Each pentest run tests one target, so splitting frontend and backend ensures thorough coverage of both surfaces.

Review your target list periodically. Remove targets for decommissioned services and add targets for new deployments. Your target inventory should mirror your actual attack surface.