Writing an effective Bug Bounty report is not as easy as it might seem if you haven’t written one before.
Getting it right is crucial for proving the validity and severity of a vulnerability and getting paid promptly and fairly for your discovery.
As with the severity score, well-written bug reports will earn points that propel you up the leaderboard and unlock lucrative new hacking opportunities.
Whether your bug is low, moderate or critical severity, the following best practices for vulnerability disclosure can build trust with security teams and earn invitations to private Bug Bounty programs.
Pre-submission checklist
Before you report a vulnerability, you should first evaluate whether it is valid under the rules of the Bug Bounty Program. Do this by answering the following questions:
- Is the vulnerability within scope? As a bug hunter, you must respect the program rules and only hunt on perimeters authorised as within scope.
- Does your bug fall within the program’s list of qualifying vulnerabilities? A non-qualifying vulnerability risks the report being rejected and closed in RTFS (Read The Fine Scope).
- Does the bug have any potential security impact? As a general rule, validation requires some direct security impact (unless the program policy says otherwise).
Impact assessment
The impact of a vulnerability directly influences the severity of your findings and, subsequently, the reward you might receive. Demonstrate impact by:
- Quantifying potential damage: Assess what data could be compromised or which functionality could be abused and to what effect. For example, could the vulnerability lead to unauthorised access to sensitive information or lead to financial losses? What is a realistic worse-case scenario?
- Using real-world scenarios: Provide a realistic attack scenario that demonstrates how an attacker could exploit the vulnerability. This helps the program’s security team grasp the practical implications of the security flaw.
- Example impact statement: “This SQL injection vulnerability could allow attackers to retrieve the entire user database, including sensitive customer information such as passwords and credit card numbers.”
Behaviour analysis
Write a behaviour analysis that explains how you identified the vulnerability by inducing the application or system into behaving abnormally. For instance:
- Understanding expected behaviour: Understand how the application or system is supposed to function based on documentation, use cases and legitimate user interactions
- Identifying anomalies: Show deviations from expected behaviour that are indicative of a vulnerability, such as unexpected error messages, undocumented features or inconsistent application responses to user inputs.
- Example behaviour analysis: “During the analysis, it was observed that submitting a specially crafted payload in the user login form caused an unusual delay in the application response. This behaviour is indicative of a time-based SQL injection vulnerability, as the application's response time varied significantly with different payloads, suggesting it was executing unauthorised SQL commands.”
Bug Bounty report layout
A report can be divided into the following sections:
Description
Description of the Common Weakness Enumeration (CWE) related to the vulnerability. This gives the reader a broad understanding of the vulnerability you discovered.
Vulnerability discovery
A description of the process of how you discovered the vulnerability.
Proof of Concept (PoC)
The PoC essentially serves as evidence that the vulnerability exists. One of the best ways to do this is to combine a short summary text with a visual reference in the form of an image and/or video.
Exploitation
A demonstration of the steps an attacker could take to exploit the vulnerability. These steps must be easy to follow so that triagers can reproduce your exploit and validate your report as quickly as possible.
You can also include an exploitation script, which is particularly handy for advanced vulnerabilities comprising numerous complex steps.
Impact
Clearly describe the impact of your vulnerability and link it to the Proof of Concept.
Remediation
Provide a technical solution for how the vulnerability might be resolved. This is not obligatory, but providing a potential fix could be a time-saver for the security team and will be much-appreciated.
References
Add links to resources that provide further context or information that will help the security team understand the vulnerability. For example, it could include URLs for the relevant CWE definition and security advisories for existing vulnerabilities that your bug can be chained with.
YesWeHack custom templates
Within your YesWeHack profile you can (once you are KYC-verified) create and store custom report templates. To create or find your templates, navigate to: Profile > My YesWeHack tools > Report templates:
When you're about to submit a report to a program, your custom templates will be accessible from a dropdown menu at the top of the page:
Here you can simply choose a Bug Bounty report template that reflects the vulnerability you are reporting. This auto-fills details adapted to the program and vulnerability you have discovered - saving you time in the process!
Top tips when writing Bug Bounty reports
Clarity is key. Ensure your report is comprehensible to all readers, regardless of their familiarity with the specific vulnerability type. The technical depth of your report should not obscure its understandability.
Remember, whoever reads your report may lack an in-depth knowledge of the vulnerability type you're reporting. To bridge this gap:
- Provide detail with diligence: Incorporate comprehensive details about the vulnerability, leaving no room for ambiguity.
- Use visual aids: Where possible, supplement your explanations with screenshots, diagrams or videos. Visual aids can significantly enhance understanding and are particularly helpful for complex vulnerabilities.
- Template creation for extra efficiency (see above section): Creating report templates for specific vulnerability types not only streamlines your reporting process for similar future discoveries, but also ensures consistency and completeness across your reports. Remember to anonymise the template by removing any program-specific details.
Vulnerability reports: your path to private Bug Bounty Programs
Poorly written Bug Bounty reports make it harder for security teams to reproduce legitimate vulnerabilities. This can lead to delays to the remediation of serious vulnerabilities or – worse still – their erroneous rejection.
It’s therefore wise to take report-writing as seriously as hacking itself. This will help to build strong relationships with programs and open doors to exclusive hacking opportunities, such as private programs or Live Bug Bounties.