Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A bug bounty researcher usually chooses a feature by working through four filters in order: whether testing is permitted, whether the asset really belongs to the program owner, whether there is a concrete security question worth asking, and whether a result could be reproduced and reported. The sequence matters. A feature that looks promising but fails the first two filters wastes time or creates legal and program risk.
The guidance below draws on public platform documentation from Bugcrowd and HackerOne and on a 2023 academic study of bug bounty participants. It is an evidence-based account of the decision process, not a personal account from one researcher, and the sources do not establish a formula that predicts which feature will produce an accepted report or a payout.
Start with the live brief, because it sets the permission boundary
Before any investigation, read the program’s current brief in full. Bugcrowd’s scope guidance says scope defines where a researcher may test, which kinds of vulnerabilities the program wants, and which testing methods are allowed. Program-specific rules take precedence over general methodology, so a technique that is standard elsewhere may be prohibited here.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check each of the following in the brief and write them down before you start:
#1 Best Overall
- In-scope assets: whether a wildcard entry such as a domain with all subdomains covers the feature you have in mind, or whether only one named host is listed. These are not the same thing.
- Out-of-scope assets and exclusions: read this section as carefully as the in-scope one. Exclusions often remove whole feature types, such as payment flows or account recovery.
- Permitted testing methods: some programs allow only authenticated accounts you create, or prohibit automated scanning, rate-based testing, or social engineering.
- Disclosure rules: how and when you may report, and what you may say publicly.
If the brief is ambiguous about a feature, treat that feature as unresolved and ask the program through its official channel rather than assuming permission.
Use program context to narrow the search
Bugcrowd’s documentation on reviewing bounty briefs describes several pieces of context that can guide where to look: target groups, rewards, program updates, known issues, and validation information. The known-issues section is especially useful. It can help you avoid areas that already have reports, or it can point you toward an area where the program has acknowledged problems and may welcome more depth.
Do not treat that list as complete. A known-issues section shows what the program has chosen to disclose, not what has been reported privately or never tested. A quiet feature is not thereby proven secure, and a feature with many known issues is not thereby the best target.
Confirm ownership before you invest time
Many feature choices start with discovery: a researcher finds a subdomain, an API host, or a new application and must decide whether it belongs to the program. Bugcrowd’s account of its Attack Surface Management work describes an approach of stepwise pivots from known baselines to related assets, checking whether each asset really belongs to the organisation, and judging how exposed it looks.
That description concerns passive research. Bugcrowd states that active testing and exploitation are out of scope for its Attack Surface Management engagements unless the program owner separately asks for it alongside a bounty or penetration test. In practice, the discovery method does not grant permission to probe. Ownership evidence, such as matching certificates, DNS records or company naming, should be sufficient to show the asset belongs to the program before any active step.
The same article puts the researcher’s role in plain terms: “Researchers are invited to provide input around the likelihood that this belongs to the client, as well as how vulnerable it is as assessed during passive exploration.” Treat both judgments as separate questions. An asset can be clearly yours and still have no plausible weakness, and an interesting-looking host may belong to a third party.
Rank #3
Prioritise features that pose a testable security question
A large or prominent feature is not automatically a good choice. A more useful test is to ask what trust boundary or permission the feature depends on, and what would happen if that assumption failed. Examples include:
- Does an object identifier in a request assume the user owns that object, and what could another account read or change if it does not?
- Does an invitation or sharing flow assume only the intended recipient can accept it?
- Does a password reset or email-change flow assume the person requesting it controls the original address?
This framing is editorial synthesis rather than a published scoring model. Its value is that it turns a vague feature into a hypothesis you can confirm or reject with a specific request sequence.
New and recently changed features
HackerOne’s Spot Checks documentation gives an official example of why a feature may be singled out. Its listed use cases include delta testing of new features or endpoints, checking coverage of a specific part of the attack surface, and examining a particular weakness. The first use case is the clearest reason for a researcher to look at a feature: code that has just shipped has had less time to be examined by others, and a change can alter an existing permission model.
To find such changes, compare the program’s public updates, release notes, changelogs, and the program’s own announcements against what you already know about the application. Record the date you observed a feature, so you can distinguish a new endpoint from one you simply had not noticed.
Coverage gaps
A second legitimate reason is a gap in what is already covered. If the program’s known issues cluster around one area, or if the feature sits between two components that have been tested separately, the interaction may be under-examined. Coverage gaps are judgments, not facts you can verify from outside, so describe them as your reasoning rather than as the program’s status.
Compare candidates on several axes, not on reward size alone
Bounty size and novelty are poor sole signals. The table below sets out the dimensions to compare when you have several candidate features. The sources reviewed contain no numeric ranking for these axes, so use them as a checklist for judgment rather than a score that predicts acceptance or payment.
Best Value
| Axis | Question to answer | What counts as a good answer |
|---|---|---|
| Eligibility | Is the asset and the planned method clearly permitted? | You can point to in-scope wording and no exclusion covers the method. |
| Attribution | Is there good reason to believe the asset belongs to the program owner? | Independent evidence links the asset to the program, such as matching DNS or certificate records. |
| Technical promise | Does passive context or a permitted first observation suggest a plausible weakness? | You can state a specific assumption that could fail. |
| Novelty and coverage | Is the feature new, recently changed, or under-examined compared with known issues? | You can name the change or gap and the date you observed it. |
| Evidence and impact | Can you show a reproducible effect and explain why it matters? | You can reproduce the behaviour with accounts and steps you control, and describe the affected data or action. |
| Researcher fit | Does the feature match your skills, available time, and learning goals? | You have the background to test the hypothesis properly within the time you can give it. |
Choose only features you can validate and report
Bugcrowd’s reporting guidance asks researchers to document reproduction steps, risk and impact, and illustrative evidence such as screenshots or video. A feature is a better use of limited time when you can test it within the rules and explain the result so the program owner can reproduce it without guesswork.
Before you commit to a feature, confirm that you can produce each of these:
- Numbered reproduction steps that use test accounts you control.
- The exact requests or actions, with the expected and observed results.
- A statement of the risk, including who could be affected and what they could do.
- Screenshots or a short video that show the result without exposing real user data.
- A check that your testing stayed within the scope and methods permitted in the brief.
If a hypothesis cannot be turned into reproducible steps within the rules, drop it and move to the next candidate. Time spent on an unreproducible idea is time not spent on a feature where the result can be demonstrated.
What the evidence does and does not establish
A 2023 preprint by Omer Akgul and colleagues, Bug Hunters’ Perspectives on the Challenges and Benefits of the Bug Bounty Ecosystem
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
