How I Learned To Write Better Bug Bounty Reports

Jul 31, 2023 Owen McCarthy

Everyone interested in submitting vulnerabilities to a bug bounty program ends up doing a Google search for “How do I write a bug report?” and finds this:

A good report is going to have this general format:

  • Title
  • Description
  • Reproduction steps
  • Proof of Concept and/or Screenshots
  • Impact
  • Remediation & Reference

Then the report gets closed as informative, and there is no payout. It’s not always the vulnerability that’s the issue. In reviewing the Bug Bounty reports we receive here at FloQast, I have seen what works and what doesn’t for a report. So instead of a summary of the sections, allow me to explain the Dos and Don’ts of each section so that you can get the full bounty for your finding.

Title

The title of your report should be concise and include the vulnerability and where to find it, such as “Open Redirect in floqast.app/login.” You want enough detail to differentiate it from other findings with the same vulnerability, but not so much that parts of the description are in the title.

Description

Describe the finding, including the information in the title. What is the vulnerability, and how did you find it? Don’t be afraid to keep this section simple, as much of the information about where you found the vulnerability and how it works can be described in more detail in the reproduction steps and impact sections.

Hackerman

Reproduction Steps

Outline the process for how the vulnerability can be reproduced for the bug bounty program to validate your finding. Include all of the necessary details on how you can demonstrate the finding, but also include details on why you took certain steps and any assumptions you make.

💡 It’s important to share why you took certain steps in your process, because it may lead to finding other places that this finding would apply and increase impact, and it can often save a lot of time in the triage and remediation steps as it can help to show mistakes you may have made.

For example, if you made an assumption about the company’s IP addresses based on a DNS lookup and that’s the reason you’re targeting a certain IP, it can save the triage process days of searching through their network resources to find an IP if they can instead tell you that they don’t own that whole IP space and that the device is not likely to be owned by the company.

Proof of Concept and/or Screenshots

This is where you will include Proof of Concept (POC) code if code is required to reproduce or demonstrate the vulnerability. Screenshots are also a great way to demonstrate the vulnerability which can save a lot of time in the validation stages of the bug bounty program.

There is no such thing as too many screenshots for a report!

Impact

This is, without a doubt, the most important section of a bug bounty report. Describe how this vulnerability can impact the company. What would happen if this vulnerability was exploited? How can an attacker use it?

Remember to focus on what affects the company most, things like:

  • Payment Card Industry(PCI) Compliance
  • Authentication
  • Databases
  • User Information

Even lower-severity vulnerabilities that affect these systems will greatly impact the company. Be honest about the real impact, don’t exaggerate the vulnerability or just claim that it can result in Remote Code Execution (RCE).

💡 A finding that can honestly say that it can lead to user information being leaked will get a big payout, while a finding that claims to lead to RCE without any evidence gets ignored.

Remediation & Reference

If you can, research your vulnerability, and include methods for fixing it and whatever further information you find. This can save a lot of time for the remediation process and get you a faster response from the bug bounty program, even if it’s as simple as a link to a related StackOverflow question.

If you can’t find anything specific, you can include general information about the vulnerability from OWASP or a CWE from http://cwe.mitre.org but don’t feel like you have to include this information if you can’t find anything helpful.

Conclusion

To make a better bug bounty report, the main things to focus on are impact and reproducibility. The main things that the company running the bug bounty program are looking for are how this finding affects their company if the finding is real, and if the fix for the vulnerability is worth it. By focusing on impact, you can show them that a fix is worth the trouble and that the vulnerability is a valuable find, and by focusing on reproducibility, they can quickly validate your finding and investigate how it can be fixed.

Remember to keep it simple. Extra information is nice, but a clear and concise description of your finding will speed up the triage process and get you a response faster.

If you have any questions or you’d like to learn more, please feel free to look through the included links in the For More Information section. If you are a FloQast employee, feel free to reach out to the AppSec team or me on Slack, we are always happy to chat about security, and we love to teach! If you aren’t a FloQast employee, feel free to reach out to me on LinkedIn or my email: [email protected].

If you are interested, check out FloQast’s bug bounty program: https://hackerone.com/floqast?type=team

For More Information

  1. https://medium.com/@tolo7010/writing-a-good-and-detailed-vulnerability-report-bdb86cedcff
  2. https://docs.hackerone.com/hackers/quality-reports.html
  3. https://www.pcisecuritystandards.org/
  4. https://cwe.mitre.org/
Owen McCarthy

Owen is a Security Engineer at FloQast. He runs the FloQast HackerOne Bug Bounty Program as well as our SAST and enjoys taking on new engineering and security projects in his spare time. Owen is always happy to chat about security or answer any questions you might have, so feel free to reach out!



Back to Blog