Before We Attack: Bug Bounty Scope and Ethics

Tonight's PWPA studies moved into the Before We Attack section of Practical Bug Bounty. The notes cover scope, duplicate reports, and the expectations that come with participating in a bug bounty program.

The previous entry on the pentest process covered agreeing on the work before testing begins. This section looks more closely at those boundaries in a bug bounty program, using Intigriti's rules as the reference.

Start with the program's scope

Scope identifies the assets an organization has authorized researchers to test. A company owning a domain doesn't, by itself, make that domain available for testing. It needs to be covered by the program's stated scope.

My notes list several reasons for keeping that boundary clear. An organization may want to focus on its core applications first, bring additional systems into the program gradually, or limit testing around services that are especially sensitive to traffic. The teams responsible for an excluded system may not be expecting security tests at all.

There are also legal consequences to getting this wrong. Safe harbor depends on the actual policy and compliance with its conditions; it shouldn't be treated as blanket protection for anything done with good intentions. If the scope is unclear, ask through the program before testing. Intigriti's scope guidance explains its approach and the importance of reading the program details first.

To turn this into a practical check: for each target, identify the scope entry that authorizes it, then check for exclusions and restrictions on the proposed test.

Read wildcard entries carefully

Intigriti's examples use two rules: a more specific asset entry takes precedence, and a wildcard can match zero, one, or multiple subdomain levels. These are Intigriti's scope conventions, so they need to be checked against the actual program rather than assumed to apply everywhere.

Consider this scope:

In scope: *.example.com
Out of scope: sub.example.com

Under Intigriti's interpretation, sub.example.com is excluded, while www.example.com and another.sub.example.com are included. The exact-host exclusion doesn't automatically exclude every deeper subdomain.

Reversing those entries changes the result:

In scope: sub.example.com
Out of scope: *.example.com

Now the exact host is included, while www.example.com and another.sub.example.com are excluded.

For the wildcard rule, an in-scope entry of *.sub.example.com includes both sub.example.com and another.sub.example.com, but not example.com. Intigriti documents these examples directly.

Writing out the expected matches makes a short scope entry easier to check. A wildcard is worth slowing down for, especially when the same list contains specific exclusions.

Finding an issue doesn't expand permission

My notes distinguish between accidentally encountering an out-of-scope issue and deliberately testing an excluded asset. If an issue is found by accident, report it through the appropriate channel and stop testing that asset. Don't assume that possible business impact gives permission to keep investigating.

It also doesn't establish an entitlement to a bounty. Intigriti may forward an out-of-scope report with clear business impact to the company for a decision, but researchers should not expect a reward. Its submission-handling guidance describes that exception.

That distinction matters when planning the next step. A report can explain what was observed and why it may matter without turning an accidental discovery into a wider, unauthorized assessment.

Think about the cause behind duplicate findings

The shorthand in my course notes is “one fix, one reward.” A useful question follows from that: would fixing the original issue also fix the others?

Finding similar behavior on several URLs doesn't necessarily mean there are several independent vulnerabilities. The same underlying problem may affect all of them. Conversely, findings that look similar may have different causes and need separate remediation.

Intigriti's submission-handling guidance distinguishes duplicate reports from related issues on that basis. Its triage standards add more context for structural issues, different hosts, and reports that demonstrate additional impact. The shorthand helps frame the question, but it isn't a universal payout rule.

A duplicate can still be a valid finding. Independently discovering something that was already reported is different from knowingly recycling a report or submitting a placeholder to claim priority. The report should describe the evidence honestly, including any uncertainty about the underlying cause.

Keep the proof and the reporting controlled

The conduct section covers what happens during testing and after a report is submitted. Several points translate directly into how a test should be planned:

Use your own test accounts and keep exposure to personal data to a minimum. Don't download or alter other users' data.
Follow automation restrictions and rate limits. Stop if testing appears to be affecting service performance.
If a vulnerability gives access to a restricted environment, stop and report it rather than continuing to explore or pivot.
Keep reports and supporting files on the platform. Public disclosure requires written approval from both Intigriti and the affected company.
Report promptly. Intigriti uses 48 hours after initial discovery as a general expectation, with qualifications for investigation and report preparation. Ask if more time is needed.
Keep follow-up professional. The code allows requests for an update every 30 days.

These points come from Intigriti's Community Code of Conduct, which should be read alongside the individual program's rules.

Questions to answer before testing

For this part of my PWPA preparation, I can use a short checklist:

Which scope entry covers the target?
Do any specific exclusions change that interpretation?
Is the proposed technique allowed, including its traffic level and data use?
What is the smallest demonstration needed to establish the issue?
What would require me to stop and ask before continuing?
Where should the finding and its evidence be reported?

The notes connect the technical work to the conditions that make it authorized and useful. Before choosing a payload or starting a scan, those conditions need to be clear.