Standard Disclosure Terms
The Submission Process
If you believe you have discovered a vulnerability, please create a submission for the appropriate program through the Crowdcontrol platform. Each program has a set of guidelines called the Program Brief. The Program Brief is maintained by the Program Owner. Terms specified in the Program Brief supersede these terms.
Each submission will be updated with significant events, including when the issue has been validated, when we need more information from you, or when you have qualified for a reward.
Each submission is evaluated by the program owner on the basis of first-in, best dressed. Bugcrowd may assist in the evaluation process.
You will qualify for a reward if you were the first person to alert the program owner to a previously unknown issue AND the issue triggers a code or configuration change.
Standard Program Rules
We are committed to protecting the interests of security researchers. The more closely your behavior follows these rules, the more we’ll be able to protect you if a difficult disclosure situation escalates.
Rules can vary for each program. Please carefully read the Program Brief for specific rules. These rules apply to all programs:
- Research should be performed only on systems listed under the Program Brief ‘Targets’ section. Any other systems are out of scope.
- Except when otherwise noted in the Program Brief, you should create a test account for research purposes.
- Submissions must be made exclusively through Crowdcontrol to be considered for a reward.
- Communication regarding submissions must remain within Crowdcontrol or official Bugcrowd support channels for the duration of the disclosure process.
- Actions which affect the integrity or availability of program targets are prohibited and strictly enforced. If you notice performance degradation on the target systems, you must immediately suspend all use of automated tools.
- Submissions should have impact to the target’s security posture. Impact means the reported issue affects the target’s users, systems, or data security in a meaningful way. Submitters may be asked to defend the impact in order to qualify for a reward.
- Submissions may be closed if a researcher is non-responsive to requests for information after 7 days.
- The existence or details of private or invitation-only programs must not be communicated to anyone who is not a Bugcrowd employee or an authorized employee of the organisation responsible for the program.
- We encourage researchers to include a video or screenshot Proof-of-Concept in their submissions. These files should not be shared publicly. This includes uploading to any publicly accessible websites (i.e. Vimeo, Imgur, etc.). If the file exceeds 50MB, upload the file to a secure online folder such as Dropbox, with a password. For more details, visit: https://researcherdocs.bugcrowd.com/v2.0/docs/reporting-a-bug.
- Bugcrowd’s Disclosure policies apply to all submissions made through the Bugcrowd platform, including Duplicates, Out of Scope, and Not Applicable submissions. Customers may select Nondisclosure, Coordinated Disclosure, or Custom Disclosure policies to be applied to their program brief. Please refer to our Additional Disclosure Policies for details on the different Public Disclosure Policies at Bugcrowd.
- If a researcher wants to retain disclosure rights for vulnerabilities that are out of scope for a bounty program, they should report the issue to the vendor directly. Bugcrowd can assist researchers in identifying the appropriate email address to contact. Customers are encouraged to ensure their program scope includes all critical components they wish to receive vulnerability reports for.
- Violation of a program’s stated disclosure policy may result in enforcement action as outlined in the Bugcrowd Terms of Service.
A violation of these rules may result in the invalidation of submissions, and forfeiture of all rewards, for current and future programs on the Bugcrowd platform.
Excluded Submission Types
Some submission types are excluded because they are dangerous to assess, or because they have low security impact to the program owner. This section contains issues that Bugcrowd does not accept, will be immediately marked as invalid, and are not rewardable.
- Findings from physical testing such as office access (e.g. open doors, tailgaiting).
- Findings derived primarily from social engineering (e.g. phishing, vishing).
- Findings from applications or systems not listed in the ‘Targets’ section.
- Functional, UI and UX bugs and spelling mistakes.
- Network level Denial of Service (DoS/DDoS) vulnerabilities.
Common “Non-qualifying” Submission Types
Some submission types do not qualify for a reward because they have low security impact to the program owner, and thus, do not trigger a code change. This section contains a listing of issues found to be commonly reproducible and reported, but are often ineligible. We strongly suggest you do not report these issues unless you can demonstrate a chained attack with higher impact.
- Descriptive error messages (e.g. Stack Traces, application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
- CSRF on forms that are available to anonymous users (e.g. the contact form).
- Logout Cross-Site Request Forgery (logout CSRF).
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Lack of Secure and HTTPOnly cookie flags.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass
- Username enumeration via Login Page error message
- Username enumeration via Forgot Password error message
- Login or Forgot Password page brute force and account lockout not enforced.
- OPTIONS / TRACE HTTP method enabled
- SSL Attacks such as BEAST, BREACH, Renegotiation attack
- SSL Forward secrecy not enabled
- SSL Insecure cipher suites
- The Anti-MIME-Sniffing header X-Content-Type-Options
- Missing HTTP security headers, specifically (http://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/)
You will qualify for a reward if you were the first person to alert the program owner to a previously unknown issue and the issue triggers a code or configuration change.
Reward details vary for each program. Rewards can take the form of USD, Bugcrowd Points, CPE Points and Swag. Please carefully read each Program Brief for specific details.
Each submission’s reward amount is based on the business impact, severity, and creativity of the issue. Bugs found in applications, features, and functions called out in the Program Brief as an “Area of Focus” are awarded at higher levels.
Bugcrowd Kudos points give you the ability to compete with others on the Bugcrowd platform, and get you access to private bounties where only the top Bugcrowd researchers are invited.
Valid submissions also count towards ISC 2 Continuing Professional Experience (CPE) credits. If you’re an ISC2 certification holder please make sure you’ve updated your ISC2 ID in the portal.
Official Support Channels and Private Communication
During the course of each program, the Bugcrowd team may communicate updates via:
- ‘Notes’ section within the program.
If you have questions about a program or a specific submission, you may contact the Bugcrowd team via:
- Crowdcontrol Submission Messages.
The Bugcrowd team can be publicly contacted via the following channels. DO NOT communicate specifics about a program via these channels.
- IRC at irc.freenode.com in the #bugcrowd channel.
Updates to these terms
All updates to this page will be listed below.
- 11:20 AM Tuesday, October 10, 2017 (PST) – Non-response submission closure policy updated from 14 days to 7 days.
- 12:00 PM Wednesday, December 2, 2015 (PST) – Removed ‘HTTPS Mixed Content Scripts’ from non-qualified submission types
- 4:30 PM Wednesday, April 29, 2015 (PST) – Added clause about communicating existence or details of private or invitation-only programs
- 10:41 AM Friday, January 02, 2015 (PST) – Lowered 30 day non-responsive clause to 14 days
- 1:27 PM Wednesday, November 26, 2014 (PST) – Added 30 day non-responsive clause
- 9:28 AM Thursday, October 2, 2014 (PST) – Added “Common “Non-qualifying” Submission Types”
- 4:54 PM Wednesday, July 30, 2014 (PST) – Added “Weak Captcha” to list of Low impact issues
- 11:28 PM Sunday, May 18, 2014 (PST) – Clarified effects of failure to abide by rules (invalidation of submissions and forefeiture of all rewards, current or future, on the platform)
- 1:28 PM Wednesday, April 23, 2014 (PST) – Added: ”
- Submissions should have impact to the target’s security posture. Impact means the reported issue affects the target’s users, system / network security, or data security in a meaningful way. Submitters may be asked to defend the impact in order to qualify for a reward.”
- 11:54 PM Tuesday, April 15, 2014 (PST) – “havelow” -> “have low”, thanks @historypeats
- 04:11 PM Wednesday, April 07, 2014 (PST) – Clarified “SSL settings” submission type
- 10:09 AM Wednesday, April 02, 2014 (PST) – Clarified support channel
- 5:01 PM Tuesday, April 01, 2014 (PST) – Clarified DOS/DDOS exclusion
- 3:04 PM Monday, March 31, 2014 (PST) – Initial Release