Bugcrowd Blog

Submission accomplished

Posted by Casey Ellis on Oct 27, 2014 9:23:22 AM

When submitting vulnerabilities via the Bugcrowd's Crowdcontrol platform, it’s important to ensure that you provide enough information for the vulnerability to be validated. Without this information, the submission may be delayed or incorrectly marked, resulting in issues with the submission process. Obviously this is something that affects both researchers and the bounty owner.

Below we’ve put together a simple comparison of a good vs. a bad submission report, which shows why this information is so important for validation of issues.


The caption of your vulnerability is the first piece of information that’s visible to the bounty owner. You only get one chance at a first impression, so try to give a descriptive title that makes it clear what the bug is.

caption_good GOOD


A well thought out caption should provide indication of what type of bug was found, and what general area of the application is affected.

Bug Type

Where possible, the type of bug should be selected from the drop down type list. If there is no specific type that matches the bug you’re reporting, then select “Bug/Other”. Selecting the correct Bug Type will show input areas for information specific to that type of bug.


URL / Location of bug

Entering the complete URL assists the bounty owner in identifying the exact location of a bug. Some applications are complex, so it’s important to know where the bug is located.

location_good GOOD

location_bad BAD

Although both technically correct, you can see how the good example above provides a link not only to the domain affected, but also to the location and function where the bug exists.

Location where XSS is accessed once stored (if relevant)

Some bugs may require additional information in order to fully understand the risk, and how they can be exploited. By entering this information, it is easier for the bounty owner to validate the bug quickly, and without requesting further clarification from the researcher.


Affected Users

The severity of a bug can be greatly affected by a number of factors. By confirming if the bug is exploitable by authenticated users only, or by all users, it is easier to validate and correctly rate the severity of issue.


Trace dump/HTTP request

In order to validate web application issues, it is important to know what request(s) were used to trigger the bug. Although the bug you’re reporting may seem obvious, this is an important piece of information for those validating the issue who may not be as technical, or understand the exact issue you’re trying to describe.

trace_good GOOD

trace_bad BAD

Affected parameter(s)

In instances where specific parameter(s) are being exploited, it is important to know which parameter(s) are vulnerable to this bug. You can list one or more parameters.

affected_good GOOD

affected_bad BAD

Attack String (Payload)

A specific test case should be provided in order for the bounty owner to quickly validate the finding and understand where the issue lies.

attackstring_good GOOD

attackstring_bad BAD

Steps to replicate

This section of the report is probably the most important of all sections, as it should contain a full walkthrough of the steps needed to exploit the issue. If this walkthrough isn’t easy to follow, then the bug may incorrectly be marked as “not reproducible” or additional information may be requested (therefore delaying the processing of the issue)

replicate_good GOOD

replicate_bad BAD

Any additional information

This field should be used to convey further information that may be useful in understanding or rating the severity of issue. If the issue is not clear, then this field can be used to explain the risks and possible attack vectors for the bug. This section can also be used to communicate possible remediation advice.

additional_good GOOD

additional_bad BAD

How did you find this bug?

Information on the method you used to find the issue


What tools did you use to find this bug?

Any special tools that you used to assist in locating or exploiting the bug



By uploading screenshots or additional documentation, it is easier for the bug to be verified and correctly handled. Uploaded files can include screenshots of the exploitation (pre and post) or other supporting documentation (POC Scripts, Log files etc…). A file attachment isn’t a replacement to the rest of the data required for this form however.

file_good GOOD

file_bad BAD

If you follow all these best practices in reporting issues via Bugcrowd then you’re in the best possible position to have a smooth and seamless experience.

Complete report comparison

Once you bring all these sections together you should now have a complete submission. If you've followed the suggestions above yours should look more like the one on the left, and less like the one on the right...

BC_GoodSubmission2 BC_BadSubmission2

Bug Hunter Tips and Tricks
Casey Ellis

Written by Casey Ellis

Executive Chairman, Founder and CTO of Bugcrowd