A good bounty scope is a short, literal list. It names the assets researchers may test, the vulnerability types you will pay for, the ones you will not, your safe harbor, reward levels and response times. If a researcher has to guess, the scope is not finished.
What OWASP says belongs in the terms
The OWASP cheat sheet says to define the scope and terms of any bounty: which systems are in scope, which vulnerability types are eligible, safe harbor provisions, reward levels and response timelines. Treat those five as your outline.
Assets
List exact hostnames, app names or repositories. Avoid wildcards unless you mean them and have inventoried what they cover. For each asset, add an owner internally, so a report about it reaches someone. Then list what is explicitly out: third party services, staging environments with real data, systems run by partners, physical offices.
Eligible and ineligible bug types
State what you want, such as authentication bypass, access control flaws, injection, and exposure of sensitive data. Then list what you do not pay for, for instance reports that rely on social engineering, denial of service by volume, or findings that need an already compromised device. A published exclusion list prevents arguments later.
Rules of engagement
- Test with your own accounts only.
- No actions that degrade service for others.
- Stop and report once the issue is shown.
- Keep data private and delete anything you saw by accident.
These match the researcher side of the OWASP guidance: stay in scope, respect privacy and be professional. See testing limits for researchers.
Safe harbor
State plainly that good-faith research within the scope is authorized and that you will not pursue legal action over it. Have counsel review it. disclose.io has model language to start from. More in what safe harbor means.
Rewards and response times
Publish a reward range by severity and say how severity is judged. Publish the times you will meet: acknowledgement, triage, and updates. Only publish times you have measured yourself against, because missing your own targets annoys researchers more than not having any.
Date the scope and keep a change log. When you add an asset, announce it. When you remove one, give notice. Review the whole scope when your architecture changes. Check readiness before launch with the bug bounty readiness checklist.
Quick check
Should we list every bug type we do not want?
List the common ones you see in practice, and add to the list as new patterns arrive. It does not need to be exhaustive on day one.
Can scope change after launch?
Yes, but announce changes and avoid applying them to reports already in progress.
Sources
- OWASP: Vulnerability Disclosure Cheat Sheet
- disclose.io: model policies and safe harbor
Last reviewed: 19 October 2026.
