At any point if you are unclear on whether a domain, asset, or IP address is in-scope or not especially as not all assets are in-scope, we strongly suggest you check through the program details. This has been worked on specifically to set out the terms of engagement for that particular program, If the domain is not listed as part of the "in-scope" section, it's automatically out-of-scope. This doesn't mean that it will remain out-of-scope, programs tend to add scope over time so keep an eye out for future updates to see if there are new assets to test.
We understand that organisations benefit from large testing scopes and that vulnerabilities not within the scope can sometimes cause significant damage. However, we adhere to a strict scope for several reasons:
Legal reasons
Our researchers are provided Safe Harbor and will not face any legal action on the condition that they follow the program’s rules. Were you to test out of scope assets without explicit permission, you may expose yourself to legal complaints. If in doubt, please use the program’s “Ask scope question” to clarify any questions you may have.
Putting the right focus
Some programs prefer to slowly expand their scope, to make sure that their core assets are covered first. This helps organisations prioritise tests and gives hackers fresh scope to work with from time to time.
Practical reasons
Some systems are very sensitive to being tested. We do not want unaware product teams to be bombarded with payloads, or unsolicited scans that may result in accidental Denial of Service.
Fairness
Focusing on assets that are out of scope and, thus, less tested provides an unfair advantage. We want to make sure that people who respect the scope do not miss out on potential bounties.
Of course, we strive to continuously evaluate scopes and make sure there is enough coverage. So, please do respect the scope. In case you find an out of scope vulnerability by accident, please do report it, but do not expect a bounty and do not knowingly continue testing the out of scope vulnerable asset. Frequently check back on the program details as there are often update which could have more scope included.
Here is how we at Intigriti typically interpret what is in-scope or out of scope
Rule 1: Most specific domain is the one that should be adhered to,
Examples:
In-scope: *.example.com
Out of scope: sub.example.com
=> sub.example.com is out of scope;
www.example.com is in-scope;
another.sub.example.com is in-scope;
In-scope: sub.example.com
Out of scope: *.example.com
=> sub.example.com is in-scope;
www.example.com is out of scope;
another.sub.example.com is out of scope;
Rule 2: Wildcard (*) character applies to none, one or more (without limit) subdomains.
Example:
In-scope: *.sub.example.com
=> sub.example.com is in-scope;
another.sub.example.com is in-scope;
example.com is out of scope;