A bug bounty report is more than just a summary of a vulnerability; it’s a professional document that showcases your skills and can directly impact your success as a security researcher. A well-written report is your ticket to a positive reputation, a strong relationship with the security team, and, ultimately, a better payout.
Here are the key indicators of a great bug bounty report:
- Faster Response Time: A clear report helps the security team understand and triage your submission quickly.
- Better Reputation: Your professionalism builds trust and a positive relationship with the bug bounty program’s team.
- Higher Bounties: A detailed, well-explained vulnerability is more likely to be understood and its full impact appreciated, leading to a higher payout.
The Prerequisites of a Successful Report
Even if you discover a highly critical vulnerability, a poorly written report can lead to its rejection. Before you start writing, it is crucial to understand the rules and nature of the specific program you are targeting. This starts with carefully reading their policy.
The Importance of the Program Policy
Reading the scope of a bug bounty program is arguably the most important step before you even begin testing. Imagine spending a week hunting for vulnerabilities only to find out the domain you tested is out of scope. Reading the policy first saves you time and frustration.
A typical bug bounty program’s policy includes the following sections:
- Mission Statement
- Participating Services
- Excluded Domains
- Rewards and Qualifications
- Eligibility for Participation
- Conduct Guidelines
- Non-qualifying Vulnerabilities
- Commitment to Researchers
Let’s break down why each of these is so important.
Mission Statement
The mission statement acts as the foreword for the entire program. It explains why the company launched the bug bounty program and their collective goal. This gives you insight into what the company values and what they hope to achieve by working with security researchers.
For example, Salesforce’s mission statement clearly outlines their core value of “trust” and their commitment to working with the security community.
“At Salesforce, trust is our #1 value and we take the protection of our customers’ data very seriously. As a result, we encourage responsible reporting of any vulnerabilities that may be found in our site or applications.
Salesforce is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process… you are in the right place.”
Participating Services
This section is a detailed, explicit list of domains and applications that are in scope for testing. It’s one of the most critical sections to analyze carefully. A common format for these domains is testingsite.com, with subdomains often specified as *.testingsite.com.
The more subdomains listed, the higher your chances of finding a vulnerability. It’s also wise to keep a close eye on this section, as programs frequently update their scope to include new targets. Bug bounty programs are generally on a “first come, first served” basis, so if you’re the first to spot a newly added target, you have a much higher chance of finding critical vulnerabilities.
Excluded Domains
Equally important is the list of out-of-scope domains. These are domains you are explicitly prohibited from testing. Some programs might list their original websites here to prevent unwanted data traffic and server downtime, directing all testing to specific test servers instead.
Testing an excluded domain can have repercussions, including being banned from the program or platform. Always review this section thoroughly before you start.
Rewards and Qualifications
This section outlines the expected bounty payouts in a clear, often tabular, format. It usually breaks down rewards based on vulnerability severity (e.g., critical, high, medium, low) and the type of application (core vs. non-core).
The payout ranges give you a clear idea of what to expect for a particular finding. This sets a benchmark for both parties and helps justify the reward amount, minimizing debate after a vulnerability has been resolved.
Bug Bounty Reward Table you can use. It categorizes rewards based on the severity of vulnerabilities (usually measured using CVSS or industry standards like HackerOne/Intigriti tiers).
| Severity | Example Vulnerabilities | CVSS Score | Suggested Reward Range (USD) | Notes |
|---|---|---|---|---|
| Critical 🔴 | RCE (Remote Code Execution), Auth Bypass, Full Database Dump, Account Takeover (no user interaction) | 9.0 – 10.0 | $2,000 – $10,000+ | Highest priority. Usually leads to complete compromise of system or data. |
| High 🟠 | SQLi with data exfiltration, Privilege Escalation, CSRF leading to account takeover, SSRF with sensitive impact | 7.0 – 8.9 | $1,000 – $5,000 | High-impact, but requires some interaction or has partial scope limitations. |
| Medium 🟡 | Stored XSS, Sensitive Info Exposure (PII leak), IDOR with limited data exposure, Weak Auth (Brute-force possible) | 4.0 – 6.9 | $250 – $1,500 | Can affect many users but usually needs some user interaction or lower exploitability. |
| Low 🟢 | Reflected XSS, Clickjacking, Open Redirect, Information Disclosure (low sensitivity), Misconfigured Headers | 0.1 – 3.9 | $50 – $500 | Low-risk, limited impact. Reward is often symbolic. |
| Informational ⚪ | Missing SPF/DMARC, Security Best Practice Recommendations, Version Disclosure | 0.0 | No Monetary Reward (Hall of Fame / Kudos) | Generally acknowledged but not rewarded with cash. |
Eligibility for Participation
This section contains the legal information about who is eligible to participate. It details criteria such as age, geographic location, and the required reporting methods. This information ensures the program complies with domestic and international laws while providing a structured process for researchers.
Conduct Guidelines
This is a critical “do not do” list. It details what a researcher must never do while hunting for bugs. While finding vulnerabilities is appreciated, certain actions can get you into serious trouble. These guidelines typically prohibit:
- Disclosing vulnerabilities to anyone else or sharing the contents of your submission.
- Accessing any private or sensitive user information.
- Performing actions that could negatively affect users or the program’s service.
- Engaging in physical attacks, social engineering, or using anything other than test accounts for vulnerability testing.
- Violating any laws or agreements.
Non-qualifying Vulnerabilities
This section explicitly lists vulnerabilities that are out of scope. These are often issues that have been reported before, are not considered a significant risk, or are a result of unsupported configurations. This is usually a long list that includes common issues like:
- Bugs in content not owned by the program.
- Vulnerabilities in unsupported browsers.
- Subdomain takeovers for out-of-scope domains.
- Self-XSS or other bugs that require unlikely user interaction.
- CSRF on forms available to anonymous users.
- Clickjacking on static pages.
- HTTP 404 or other non-200 status code pages.
- Fingerprinting or public information disclosure.
- Automation, scripting, or brute-forcing intended functionality.
- “Save password” functionality.
- Lack of secure/HttpOnly cookie flags or missing HTTP security headers like Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.
Commitment to Researchers
This part of the policy outlines how the program will handle your report. It shows how much the program vendors value researcher feedback and are open to receiving vulnerabilities. Typically, a good program will commit to:
- Responding in a timely manner to acknowledge your report.
- Providing an estimated time of arrival (ETA) for their review.
- Investigating and considering the report for eligibility within a set timeframe (often 30 days).
- Notifying you when the vulnerability has been fixed.
Salient Features of a Good Bug Bounty Report
Beyond the technical details, every report shares a set of common features that provide extra insight into the identified vulnerability. These pointers can help you craft a professional report.
Clarity
Your report should be clear and concise. Avoid language that is pushy or emotional. Compare these two examples:
Unclear:
“I would like to report a very critical using which you can takeover user accounts and should be fixed ASAP.”
Clear:
“This report contains technical details about a vulnerability in the password reset function which can allow users to take over accounts.”
The second example is straightforward and professional. It immediately informs the reader about the type and impact of the vulnerability.
Depth
The person reading your report knows as much about the vulnerability as you tell them. Your report should focus on the technical aspects and provide sufficient detail. This shows that you are not just “beating about the bush” but are genuinely trying to help them improve their security.
Estimation
The report should allow the program owner to quickly determine the severity and potential bounty. This is only possible if you have done a thorough job of testing the vulnerability and have clearly communicated its impact. Avoid speculative or vague language about the potential reward.
Respect
This is one of the most important aspects of your report. Being respectful to the program’s owners and vendors gives off a positive vibe and helps build trust. A professional and respectful tone can make a significant difference in how your report is received, even if the finding is not as critical as you thought.
The Format of a Bug Bounty Report
A well-structured report can make a huge difference in your success. While the specific format may vary, this structure provides a clear and effective template for reporting.
Writing the Report Title
The title is the first thing the program owner sees. It should be explicit and to the point. Titles with emotional language or over-the-top claims are not viewed positively. A straightforward title demonstrates maturity and experience.
Bad Report Titles:
- Urgent! SQL injection found
- Attention! Critical vulnerability
- Very critical account takeover flaw
Good Report Titles:
- Union-based SQL injection in developer’s portal
- Hostile subdomain takeover in
admin.xyz.com - Account takeover using password reset token
Writing the Report Description
The description should be precise and concise. Program owners want to quickly understand the key points without having to read a long, generic wall of text. The description should be specific to the environment and the scenario you tested.
To help the program owners understand and resolve the issue, provide reference links from reputable technical resources like the Open Web Application Security Project (OWASP) or Stack Overflow. However, avoid copying and pasting descriptions from automated tools. This gives a poor impression and suggests a lack of effort.
Here’s an example of a good report description:
“Your web authentication endpoint, https://hackerone.com/sessions (POST), currently protects against credentials brute-force attacks only by requests rate-limiting based on IP. It was found that if an attacker sends login requests faster than every 4 seconds from the same IP address, it would get blocked. This still allows an attacker to make the following number of guesses from one single system: 15/minute, 900/hour, 21.600/day or 648.000/month. No additional protection mechanisms such as Captcha (pre-auth) or account lockout requiring additional email/phone verification (pre- or post-auth) were identified at any time. This allows for brute-forcing of credentials, for example based on breached clear-text password databases of which there are many publicly available https://wiki.skullsecurity.org/Passwords.”
Writing the Proof of Concept (PoC)
Without a clear Proof of Concept (PoC), the team cannot replicate your finding. You must list the replication steps exactly as you performed them. Think of the program owner as a new user and provide simple, easy-to-follow, step-by-step instructions.
This hierarchical approach helps the triaging team confirm the validity of your issue quickly. For example, for an XSS vulnerability, your steps might look like this:
- Go to the following URL:
https://example.com/search. - Log in using your username and password (an account is required).
- In the search box, insert the following payload:
"><script>alert(document.domain)</script> - Click the “Lookup” button.
- You will see a JavaScript popup box displaying your domain.
Adding screenshots or a video recording can be incredibly helpful. Visual aids are highly appreciated by busy teams who may be reviewing hundreds of reports a day. To further demonstrate the severity, you should also describe a possible exploitation scenario. Explain how a malicious actor could use this flaw and what the organization or its clients could lose as a result.
Writing About Exploitability
As a security researcher, you need to clearly demonstrate how likely it is that the vulnerability you found poses a significant threat. If the exploitation is easy and straightforward, it’s more likely to be rewarded with a higher bounty. The value of your report increases significantly if you include at least one real-world attack scenario that shows the vulnerability’s potential impact. This helps the team understand the practicality and seriousness of the flaw.
Writing About Impact
The impact statement is another crucial part of your report. By this point, the security team understands the vulnerability, but detailing its impact helps them escalate the issue to management and developers. Remember, your report will be read by different people, and program owners often need to convince developers that a fix is a priority.
An impact statement makes the vulnerability’s real-world consequences tangible. The best way to help the development team understand the severity and secure a good bounty is to include this section. Consider the program’s business model and highlight the most relevant threat. For example, in a fintech company, emphasize the exposure of financial data. In a Health Tech company, highlight the risk to patients’ data. However, there is a fine line between being impactful and being pushy. Avoid over-emphasizing the threat, as this can negatively affect the delivery of your report.
Writing About Remediation
Once you’ve completed the report, it is highly beneficial to suggest fixes and patches for the vulnerability. This demonstrates to the program owners that you’re not just a flaw finder but a problem solver. Your suggestions should be specific, not generic. Instead of saying “sanitize the inputs,” provide references or probable methods to implement a solution. The development team may not always know how to fix a vulnerability, and a clear, well-stated remediation suggestion will be greatly appreciated.
Responding to Team Queries
After you submit your report, the team will review it. If your report is clear and thorough, it may be accepted quickly. However, it’s common for the team to have questions, which is natural and shouldn’t diminish your confidence.
Here are some tips on how to handle their queries:
- Always be respectful. Maintain a professional and courteous tone in all your communications.
- Never ask about the resolution or fix timeline. This can be perceived as pushy.
- Include more technical details with every comment. Be thorough and provide any additional information they might need.
- Have patience. The team is likely working on many other reports.
- Ask about the bounty only after the issue has been resolved.
- Accept rejection politely. If the team rejects your report but you still believe the issue is valid, you can politely interject with more compelling information.