Recently, a friend reached out to me for a simple Bug Bounty vulnerability disclosure policy. While combing through my vulnerability disclosure polices library, I realized there wasn’t an acceptable policy to be found.
The default policies for the popular bug bounty platforms leave much to be desired or are wrapped in legalese not easily understood by those whom English is a second / third language.
Below is a simple policy which can be applied to ones’ bug bounty program. Enjoy!
Vulnerability Disclosure Policy
INSERTENTITYNAME is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.
Program Rules
- Automated testing is not permitted.
- Follow INSERTBUGBOUNTYPLATFORMNAME’s Disclosure Guidelines - URL TO BUG BOUNTY PLATFORM DISCLOSURE GUIDELINES
- Test only with your own account(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.
- You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.
- We award bounties at time of fix, and will keep you posted as we work to resolve them.
- Contacting our support team (support@
) about the status of a INSERTBUGBOUNTYPLATFORMNAME report will result in an immediate disqualification for a bounty for that report.
Exclusions
The following bugs are unlikely to be eligible for a bounty:
- Issues found through automated testing
- "Scanner output" or scanner-generated reports
- Publicly-released bugs in internet software within 3 days of their disclosure
- "Advisory" or "Informational" reports that do not include any INSERTENTITYNAME-specific testing or context
- Vulnerabilities requiring physical access to the victim's unlocked device
- Denial of Service attacks
- Brute Force attacks
- Spam or Social Engineering techniques, including:
- SPF and DKIM issues
- Content injection
- Hyperlink injection in emails
- IDN homograph attacks
- RTL Ambiguity
- Content Spoofing
- Issues relating to Password Policy
- Full-Path Disclosure on any property
- Version number information disclosure
- Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)
- CSRF-able actions that do not require authentication (or a session) to exploit
- Reports related to the following security-related headers: Strict Transport Security (HSTS) XSS mitigation headers (X-Content-Type and X-XSS-Protection) ** X-Content-Type-Options
- Content Security Policy (CSP) settings (excluding nosniff in an exploitable scenario)
- Security bugs in third-party applications or services built on INSERTENTITYNAME's APIs - please report them to the third party that built the application or service
- Security bugs in software related to an acquisition for a period of 90 days following any public announcement
- Former INSERTENTITYNAME employees within one year of their departure from INSERTENTITYNAME
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
Thank you for helping keep INSERTENTITYNAME and our users safe!
Scope
There are far too many posts about determining scope. if you are not sure what to do, the below scope and severity is a great start.
