Bug Bounty Reports - How Do They Work?

Better bug reports = better relationships = better bounties. Whether you are new to bounty programs or a bounty veteran, these tips on how to write good reports are useful for everyone! These tips can help you achieve...

• ...quicker turnaround time from the security team responding to your request
• ...better reputation and relationships with the security team
• ...higher chances of getting a bigger bounty

Know your audience!

Not all bug bounty programs are born equal. Some are run by an entire crew of 31337 h4x0rz like yourself, while some might be staffed by a single person who’s responsible for all of IT and security for an entire company! Knowing who (and what) you are dealing with can make a huge difference in your interactions with a bounty program. Here are some quick tips to better understand programs you’d like to submit bugs to:

What’s in scope?

This is probably the most important thing to figure out before you do anything! You know what sucks? Spending a week hacking on a domain, submitting five reports, and discovering they’re all out of scope. That can be frustrating! You know what’s way easier? Taking a few minutes to check out the program’s rules page look for the “scope” section. Is their rules page missing a scope? If so, just ask! There’s no harm in submitting a report to ask first before wasting a bunch of time on something that turns out not to be in scope.

Where’s my response?

As mentioned above, all programs are different. One program may get back to you in an hour, another in a day, another in a couple of weeks! Check the program’s rules page to see if they have an SLA (service-level agreement) or best effort time to response. If it says clearly in the rules page that the organization will try their best to respond within 5 business days, but you ask them for an update on days 2, 3, and 4… you’re gonna have a bad time. This will sour your relationship with the security team and make it obvious you didn’t read their rules page. It’s great to be proactive and ask for updates, but do it at a reasonable pace. If there isn’t an SLA listed on their rules page, once again, don’t be afraid to ask!

They said it wasn’t an issue… but it is!

Not all vulnerabilities mean the same thing to every program out there. Context is huge. A cross-site scripting (XSS) bug on a domain meant primarily for housing session info and access to perform sensitive actions is way more valuable than clickjacking on a page that has no state-changing functionality. Even beyond the content, there’s the product itself - how would you value a user information disclosure on Twitter vs. user information disclosure on Pornhub? If this happens, your first step should be to think about the context and what the security impact is relative to the affected organization.

If it still seems like it’s an issue, and the security team hasn’t already done so, it’s okay to ask for clarification on why they feel it is a non-issue. At the end of the day, it is every organization’s responsibility to determine what meets the bar for a bounty or other recognition. Arguing with a security team or submitting a report multiple times after they’ve told you they do not consider it to be an issue is poor form, and honestly, usually isn’t worth the time you could spend finding a higher impact issue. All of that said, if you still feel strongly that the security team has made a mistake, you can request mediation from HackerOne, or, if the organization firmly stands behind it not being an issue, you can request public disclosure. The following sections on how to construct your reports will help you proactively avoid situations like this.

The report itself

There are three topics that you must cover in any good report: reproduction steps, exploitability, and impact.

Reproduction Steps

Without repro steps, how will the security team know what you’re telling them is a real issue? Having clear, easy to follow, step-by-step instructions will help those triaging your issue confirm its validity ASAP.

Here’s an example:

Bonus points if you include screenshots highlighting the reproduction steps - this makes it even easier to reproduce the issue.

A note on video recordings: These can be hit or miss, and really depend on the security team and the bug. Sometimes, for complex bugs, a video demonstrating the vuln can be useful. However, some teams are triaging hundreds of reports a day - can you imagine how much time it would take them to watch that many videos? As always, if in doubt - ask, or offer a video demonstration and let the security team tell you if it’s needed.

Exploitability

Okay, so now the team knows it’s a real bug… but how likely is it this would be exploited? If something’s really easy to exploit, it may warrant a higher bounty! The opposite is also true. It’s important to think through at least one attack scenario and describe it clearly to increase your chances of a reward. How would this bug be exploited by a real attacker?

Here’s an example:

Impact

Okay, so now the security team knows it’s a real issue, they know it can be exploited… but so what? (Wait, what?) It might be obvious to you what the impact is, and in some cases, it might even be obvious to them! However, keep in mind that each of these security teams need to share your report internally and probably convince other developers to spend time fixing the issue you’ve helpfully uncovered. The easiest way to both help ensure the security team and developers understand how important the bug you found is, as well as to help improve your chances of a solid bounty, is to help explain what the security impact is.

Here’s an example:

Try to step into the shoes of the security team and think what’s most important to them. Is it a healthcare company? If your vulnerability could expose patient data, highlight that. Is it a company that processes credit cards and is subject to PCI compliance? Explain how this vulnerability could leak credit card details of their customers. That said, don’t “stretch” your vulnerability or lie to make it sound like it has more impact than it actually does - this is in poor taste and will sour your relationship with the security team; be honest!

A note on deep context: Sometimes, it's simply not possible to have all the info that a security team does. If you think you've found something interesting but aren't 100% sure what the impact is, don't be afraid to submit the report and ask.

Awesome Reports IRL

Here are a few examples of well-written reports you can look to for inspiration:

WordPress Flash XSS in flashmediaelement.swf
SSRF in https://imgur.com/vidgif/url
Subdomain takeover due to unclaimed Amazon S3 bucket on a2.bime.io
Bypassing password authentication of users that have 2FA enabled

Wrapping it up

Hopefully these tips helped you learn something new, or maybe remember some best practices that were forgotten along the way. Following these guidelines will greatly increase the quality of your reports, and even help you ensure you’re spending your time in the best way possible on easily exploitable, high-impact issues that’ll net you big bounties.

Do you have other tips? If so, let us know by emailing us at hackers@hackerone.com!

Adam Bacchus

HackerOne is the #1 hacker-powered security platform, helping organizations find and fix critical vulnerabilities before they can be criminally exploited. As the contemporary alternative to traditional penetration testing, our bug bounty program solutions encompass vulnerability assessment, crowdsourced testing and responsible disclosure management. Discover more about our security testing solutions or Contact Us today.