What does a good report look like?

Legend has it that the best bug bounty hunters can write reports in their sleep. OK, jokes aside, while writing reports is a very important part of bug bounty hunting, we can simplify this whole process by following these basic guidelines.

Summary

The first section of your report should start with a brief summary introducing the reader to your finding. Summaries can be as simple as:

example.com is vulnerable to reflected XSS via the q parameter.

Or as detailed as:

https://imgur.com/vidgif/url endpoint is vulnerable to a SSRF vulnerability which allows an attacker to craft connections originating from imgur servers to any destination on the internet and imgur internal network and craft outgoing UDP-packets / telnet-based protocol sessions (for example, to connect to SMTP servers from imgur and send spam). [1]

Vulnerability Description

This section covers all the details related to your finding. State what you found again, make the technical points clear, and explain what causes the issue. There are exceptions though where this section can be skipped. There is a popular English idiom:

"A picture is worth a thousand words."

The same can be said about an excellent proof of concept:

"A phenomenal security vulnerability proof of concept is worth a thousand words."
- Probably Gandhi

Proof of concept

The proof of concept is where you really need to demonstrate the impact in the "flashiest" way possible. Make it as easy as possible for the program to see what the issue is. If your issue is cross-site scripting, then an alert(document.domain) can go a long way to help the program figure out where the issue lies.

Browsers verified in

Even if the issue is not browser-dependent, it is good practice to inform the program about what browser you used to trigger the vulnerability. This can help the team behind the bug bounty program reproduce your finding.

Mitigation

If you followed the advice in "How do I get started with bug bounty hunting?", you should be capable of giving a brief description of how the bug bounty program should fix your finding. It is also a good idea to link to the relevant OWASP Prevention cheat sheet.

Spellcheck

I highly recommend running Grammarly, or a local spell-checking tool, to find spelling mistakes in your report prior to submitting. Some may argue that if your report contains sensitive information you should not be running it through a third-party, so keep that in mind when spell checking your report!

Altogether...

# Summary
...

# Vulnerability details
...

# Impact
...

# Proof of concept
...

# Browsers verified in
...

# Mitigation
...

Templates

Writing reports can be repetitive work and in a competitive environment every minute is crucial, therefore having templates for different vulnerability types can be a big help. Frans Rosén, one of the smartest bug bounty hunters in the industry, published a tool that fills in template reports for you. Get started writing up all sorts of templates and make sure to cover all the points listed in the previous section!

$ git clone https://github.com/fransr/template-generator
$ cd template-generator
$ php -S localhost:8000