Researcher Documentation

Welcome to the researcherdocs developer hub. You'll find comprehensive guides and documentation to help you start working with researcherdocs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started

Reporting a Bug

You've done the work: you've found a bug or vulnerability. Now it's time to file a report to disclose your findings.

Generally, you'll need to explain where the bug is, who it affects, how to reproduce it, the parameters it affects, and provide Proof-of-Concept supporting information. You can upload any files or logs you have as supporting evidence that the vulnerability exists. You want to add as much information as you can to help reproduce the vulnerability. Some bugs will require additional information. Some will require less. It depends on the type of vulnerability you are reporting. This not only helps quickly reproduce the issue but moves your submission through the review process a lot faster, with no delays due to missing information.

Here's what the report should contain, at a minimum:

  • Info

This will be the title of your report, and should describe the type of bug found, where it was found, and the overall impact. For example, “Remote File Inclusion in Resume Upload Form allows remote code execution” is much more descriptive and helpful than “RFI Injection found."

  • Target

The Target field identifies the specific target affected by the bug you have found.

  • Technical Severity

The Vulnerability Rating Taxonomy Classification identifies the kind of bug you have found based on our VRT, our baseline priority rating system for common bugs found on bug bounty programs. It is important that you choose the correct type so that the organization understands the risk the bug presents them. Note: The severity rating suggested by the VRT is not guaranteed to be the severity rating applied to your submission once impact has been considered.

  • Vulnerability details:

This section should include the following information:

  • Bug URL – The bug URL identifies the location in the application where you discovered the bug.
  • Description – Your report must include clear and descriptive replication steps so that the organization can easily reproduce and validate that your findings.
  • Additional information – Provide additional context! Explain clearly what it is that you have discovered and describe the risk and impact to the specific Program Owner what you discovered and describe the impact and risk.
  • Screenshots or videos – Provide illustrative evidence in the form of screenshots or videos that shows proof of the vulnerability. This is one of the most impactful things you can do to provide context around your submission. We strongly recommend you provide this every time you submit.

Creating a Vulnerability Report

  1. From the bounty brief, click the Submit Report button.
  1. When the report form appears, enter a name for the report in the Info field. The summary should be descriptive and concise.
  1. Choose the target that is affected, if you do not see the target listed choose "Other".

NOTE: Out of Scope Targets

Before selecting “Other”, take another look at the program's brief and be very sure that the target affected is not listed as "Out of Scope" or does not include other similar instructions. Submitting against a target which is listed as Out of Scope will result in a -1 point adjustment. Repeatedly testing outside the approved scope will result in loss of program access or platform privileges.

  1. Select the Technical Severity of the vulnerability, this drop-down list is based on our VRT (Vulnerability Rating Taxonomy). You can start typing to filter the list by match.
  1. Enter the location of the vulnerability, such as the URL.
  1. Enter organized, clear, and descriptive replication steps so that the assigned Application Security Engineer can easily reproduce and validate your findings.
  1. Input a Trace Dump or the HTTP request.
  1. We strongly recommend uploading illustrative evidence that shows proof of the vulnerability, preferably in the form of a POC video showing the vulnerability in the Program Owner’s system or screenshots at minimum.
  1. Verify that you have followed all requirements of the program brief and that you agree to abide by the Bugcrowd Terms and Conditions.
  1. When you are done, click the Report Vulnerability button to submit the report.

After you submit your report, Bugcrowd sends you an e-mail that confirms that we've received your submission.

When the status of the report changes or someone comments on your report, you will be notified via e-mail or through your submission. Please ensure that you promptly respond to any assigned blockers on your submissions, as these mean that we need more information to process your report.

Uploading an Image or Video

It's important to include as much information as possible to help the person reviewing your submission understand the issue, reproduce the issue, and identify how they can fix it.

Screenshots and proof-of-concept (POC) videos are great because they can provide clear and exact replication steps for your submission. If you have recorded your session or have any file that can be used as evidence, please upload it to the submission as a file attachment. All file types are supported, but please keep individual upload size under 100mb. You may upload up to 5 files.

Click here for detailed instructions on how to upload video or images with your submissions.

Writing a Good Bug Report

When you're writing a bug report, it is vitally important that you remember the audience that will be reading your report. Bugcrowd and Program Owner Analysts may not have the same level of insight as you do into the specific vulnerability, so provide clear, concise, and descriptive language when writing your report.

  • Organize your information
    Clear explanations – Order your report in the exact progression of steps which should be followed, in order to replicate the vulnerability successfully.

  • Explain clearly – It is so important that you write your report clearly and with purpose. Help the reader understand the security impact, replication steps, and the actions that need to be taken to address the issue, so that the submission can be processed quickly without the need for additional information.

  • Well documented attack scenarios – Attack scenarios tell the program owner why they should care about the vulnerability - this is the impact of the vulnerability.
    Example:
    "This vulnerability affects all users of your forum. When a user signs up, and enters a username of XYZ@Customer.com and a password of XYZ@Customer.com, then their username is accepted. An attacker could use this vulnerability in conjunction with a username enumeration issue to bruteforce forum usernames and passwords."

For more resources on writing bug reports, check out the following blogs:

Review the Disclosure Policy for the Program

It may be tempting to share your findings with others, but remember:

Important

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 organization responsible for the program.

All submissions made through the Bugcrowd platform, including Duplicates, Out of Scope, and Not Applicable submissions are covered by the Bugcrowd Standard Disclosure Terms, and vulnerability may NOT be shared without permission or unless otherwise explicit stated on the Program's brief. Program Owners may select Nondisclosure, Coordinated Disclosure, or Custom Disclosure policies, and list these on their program brief.

Failure to keep vulnerability data private is considered an unauthorized disclosure, and may result in loss of program access or platform privileges.

Updated about a year ago

Reporting a Bug


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.