Overview
As in all security testing, authorization is the foundation of bug bounty — the program's policy is the authorization, and staying within it is mandatory. This lesson covers authorization in bug bounty.
Learning objectives
- Explain authorization in the bug bounty context.
- Identify the program policy as the authorization boundary.
- Understand the consequences of exceeding it.
Core concept
In bug bounty, authorization comes from the program policy: by publishing a program, the organization grants permission to test the in-scope assets under the stated rules — and only those. The policy is a binding boundary: testing in-scope assets within the rules is authorized (legal); testing out-of-scope assets, or using prohibited techniques, is not authorized and can be illegal, even if the researcher meant well. Authorization is therefore scoped and conditional on following the policy exactly.
How it works
Before testing, the researcher reads the program policy to understand precisely what is authorized: which assets, which techniques, any constraints. They then test strictly within that authorization. If they discover an interesting but out-of-scope asset, they do not test it — the program did not authorize it. Exceeding the authorization (testing out-of-scope systems, using prohibited methods, or violating rules) forfeits legal protection and can lead to serious consequences. The program's authorization is the researcher's shield only while they stay within it.
Practical example
A researcher joins a program whose policy authorizes testing of app.example.com but explicitly excludes legacy.example.com and any third-party services. The researcher tests only app.example.com within the rules. Noticing legacy.example.com is interesting, they do not test it — it is out of scope, so testing it would be unauthorized and illegal, regardless of intent. They stay within the program's authorization, which is what keeps their research legal.
Cybersecurity relevance
Authorization is the legal and ethical bedrock of bug bounty, exactly as in professional engagements: the program policy defines it, and exceeding it turns legal research into unauthorized access. Researchers must treat the scope and rules as strict boundaries — many legal problems in bug bounty arise from testing out-of-scope assets or violating rules. Respecting authorization protects the researcher and the organization and preserves trust in the bug bounty model. This reinforces the ethical-hacking path's authorization principle in the bug bounty setting.
Common mistakes
- Testing out-of-scope assets, forfeiting authorization and legal protection.
- Using prohibited techniques the policy disallows.
- Assuming good intent excuses exceeding the program's authorization.
Key takeaways
- In bug bounty, the program policy is the authorization — permission to test the in-scope assets under the stated rules, and only those.
- Authorization is scoped and conditional; testing out-of-scope assets or violating rules is unauthorized and can be illegal despite good intent.
- Respect scope and rules as strict boundaries; authorization protects the researcher only while they stay within it — reinforcing the ethical-hacking authorization principle.
Check your understanding
- What is the source of authorization in a bug bounty program, and what does it cover?
- What should a researcher do upon finding an interesting but out-of-scope asset?