Targets & Scope: Defining In-Scope Assets on Hackrate

Scope definition is one of the most consequential decisions you make when running a security program. A well-defined scope attracts focused, high-quality research, protects your production systems, and sets clear expectations that prevent disputes about report validity. A vague or poorly written scope leads to off-target testing, wasted researcher effort, and confusion for your triage team. This guide explains how to configure targets on Hackrate and how each field affects the researcher and reporting experience.

​

What is a target?

A target is an individual asset that you add to a program’s scope. Each program can have multiple targets, and each target is configured independently. Researchers see the full list of active, in-scope targets when they view the program — this is how they decide where to focus their efforts. Every target has the following properties:

​

In scope vs. out of scope

Every program on Hackrate has both an in-scope list (assets researchers are authorized to test) and an out-of-scope list (assets they must not touch). Being explicit about both is equally important. Common categories to consider for out-of-scope designation:

• Third-party services and SaaS platforms you use but do not own
• Shared hosting infrastructure
• Rate-limiting and anti-brute-force mechanisms (often excluded to prevent DoS)
• Social engineering and physical security testing
• Denial-of-service (DoS/DDoS) attacks
• Automated scanning at a rate that degrades service performance

​

Tier 1 vs. Tier 2 assets

The tier system allows you to pay differentiated bounty amounts based on how critical an asset is to your business. This creates the right incentives: researchers spend more time on your highest-value targets because the potential reward is higher.

​

Best practices for scope definition

​

Be specific with asset names

Avoid vague names like All web applications or Backend services. Instead, name each asset specifically:

• ✅ app.yourcompany.com — Customer Portal (Vue.js frontend + REST API)
• ❌ All customer-facing apps

Specific names help researchers understand exactly what to test and help your triage team quickly confirm which asset a report relates to.

​

Write meaningful descriptions

The description field appears on the program’s public scope page and is visible to researchers before they begin testing. Use it to explain:

• What the asset does and who uses it
• The technology stack (if you are comfortable sharing it)
• Any known constraints or guidance (for example, “Test accounts are available via the credential request system”)
• Any historical context relevant to testing (for example, “This API was recently rewritten and is a high priority”)

​

Separate test environments from production

If you want researchers to test against a staging or test environment rather than production, create a separate target for each and name them clearly:

• Main App — Staging (app-staging.yourcompany.com)
• Main App — Production (app.yourcompany.com)

You can then configure the staging target as active and in-scope, and leave the production target as active but with tighter restrictions in the policy.

​

Refresh your scope regularly

Your product changes over time — new features are shipped, old services are deprecated, and the attack surface evolves. Review your target list at least quarterly and:

• Deactivate targets for assets that no longer exist
• Add targets for new assets
• Upgrade Tier 2 targets to Tier 1 if their criticality has increased
• Update descriptions to reflect architectural changes

​

Adding targets to a program

Targets are managed from the Scope section of your program management page. Contact the Hackrate team to add new targets or modify existing ones — this ensures the change is reviewed and that researchers are notified appropriately when scope expands.

​

Deactivating targets

If you need to remove an asset from scope — for example, because it has been retired or because you need to take it offline for maintenance — you can deactivate the target rather than deleting it. Deactivated targets are hidden from the public scope table and from researcher view, but they remain in your program’s history along with any reports associated with them.

​

Providing test credentials

Many web applications and APIs require authenticated access to test properly. Hackrate’s credential management system lets you securely provision test accounts to researchers.

​

How credentials work

You upload test credentials (username and password pairs) via a CSV file or the credential dashboard. The platform assigns unique credentials to each researcher who joins the program, ensuring:

• No two researchers share the same test account (preventing one researcher’s actions from interfering with another’s)
• Each researcher knows which account is theirs
• You can audit which researcher was using which account if an incident occurs

Credentials can be configured at two levels:

• Program-wide — A single set of credentials grants access to the entire program’s test environment
• Target-specific — Different credentials for each target, where each asset has its own authentication system

​

Setting a credential quantity per target

For targets where you want each researcher to receive multiple test accounts (for example, to test different user roles), you can configure how many credential sets each researcher receives per target. If this is set to zero, each researcher receives one credential set by default.