How to write a good report
Writing a good report is as important as finding the vulnerabilities. Providing an unclear proof of concept can slow down the process of triaging your submission. So in this article we will give you some tips on how to increase the chance of your report getting accepted. You may also feed this to your AI agent and use it as an extension for your report writing workflow.
General rules
Before you dive deeper into what your submission should look like, keep these ground rules in mind. Getting these right from the start saves time for both you and the triage team.
Read the program details. Verify that the asset is in scope and that the vulnerability class you're about to report isn't explicitly excluded. A large number of non-applicable submissions come from researchers who skipped this step. Spending ten minutes reading the program details before a submission is always worth it.
One vulnerability per report. If you've found three separate issues, submit three separate reports. Bundling unrelated findings into a single submission slows triage, complicates severity assessment, and often results in the entire report being under-rewarded.
Write in English. Most programs operate in English, and triagers need to understand your submission clearly to validate it.
Protect other users' data. Always use test accounts you own or accounts explicitly provided by the program for testing purposes.
Chaining vulnerabilities. If your finding is a chain of multiple issues that together demonstrate higher impact, submit it as one report and document each step of the chain clearly. Show how each piece connects to the next and what the combined impact is.
Respond to follow-up questions. Once you've submitted, stay available. Triagers often have follow-up questions, and a slow response stalls validation. Check in regularly, especially in the first few days after submission.
Answer submission questions. Some programs ask for your public IP or time of testing to correlate your testing activity with potential misuse. Be sure to respond to such questions, as some are mandatory and may result in a bounty penalty when not followed up on.
Follow the Community Code of Conduct. Refrain from public disclosure without prior approval from the company, avoid threatening or pressuring companies, and never share details in public channels before the issue is resolved.
Be respectful and kind. Triage teams are people working through a queue, often across multiple programs and time zones. A professional and respectful tone goes a long way.
Learn how to appeal outcomes professionally. It's okay to not agree with a triage decision. If you come across a situation where you disagree with a triage decision, there's a right way to raise it. We've put together a separate guide on how to appeal a submission outcome professionally and effectively.
We're here to help. Ultimately, our goal is to see you succeed and rank high on the leaderboard. A well-written report isn't just good etiquette, it's the easiest and fastest path to a bounty.
Let's get into the more important phase now: Report writing!
1. Submission title
The title is the first thing a triager sees, and a good one sets the right expectations immediately. Keep it short, specific, and structured. Use the following format:
[<ASSET>] - <Vulnerability Type> - <Endpoint or short description>
A few examples of what this looks like in practice:
[www.example.com] - Reflected XSS - /404?ReturnPath=[api.example.com] - IDOR - /api/v1/users/{id}/profile[app.example.com] - SQL Injection - /search?query=
Avoid including full URLs in the title. Keep the endpoint short and representative. Generic titles like "XSS vulnerability found" or "Security issue on login page" tell us nothing about the asset, the vulnerability class, or where it lives.
Also try to avoid too verbose titles. If your title needs more than one line, it's too long and can probably be shortened.
2. Description
The description is where you explain what the vulnerability is, why it exists, and why it matters, so try to keep it concise.
Start by describing your current behavior you observed and the vulnerability type. Then explain why this behavior shouldn't be possible or can be used maliciously. Ideally, you'd want to avoid being too verbose too, for instance, you are not expected to write an entire chapter on how reflected XSS works or when the client-side injection type emerged.
This counts for LLM-generated descriptions too. AI is well-known for being verbose by default. Therefore, it's best practice to avoid lengthy descriptions that provide no real value. Remember, the goal is to give just enough context to understand the issue before following the reproduction steps.
3. Proof of concept / Steps to reproduce
This is the most important section of your report. A triager should be able to reproduce your finding by following your steps exactly, without any additional context or guesswork. Always validate your proof of concept before submitting, preferably with new accounts and/or in a new, non-configured instance. Reproducing your own submission with new test accounts or instances will help you catch any missing requirements, such as dependencies.
Do remember that you always bear full responsibility for sending in an unvalidated submission.
Requirements
If your reproduction requires specific accounts, roles, or permissions, list them first. State clearly whether you need two separate accounts, an admin or a standard user, or any particular configuration. Never assume the triager has this set up already.
Additionally, if a request requires a specific token (such as a JWT or an anti-CSRF token), ensure you provide the steps on how to obtain them too.
Navigation
Always assume the triager is opening the target for the first time. If the vulnerable feature is several levels deep in the application, help them navigate there. For example, "Navigate to Settings > Integrations > API Keys" is far more useful than leaving them to search for it.
Steps to reproduce
Your steps should be numbered, factually correct, and written in the exact order they need to be performed. Test them yourself before submitting. Every step you write is a step the triager will execute, and if one of them is wrong, they'll likely have to ask you for more feedback, further increasing time to triage.
For instance, if a specific parameter value matters, do include it. If an HTTP request needs a particular request header, mention it as well. Try to be as precise as possible.
Important! Your steps to reproduce must always list the simplest path to reproduction. As asserted in our Triage Standards:
"All submissions are required to come with a written, step-by-step demonstration of an attack. This should be the simplest possible demonstration that proves the vulnerability's exploitability and impact beyond reasonable doubt. [...]"
Scripts and HTTP requests
You're welcome to attach proof-of-concept scripts, but keep dependencies minimal. We cannot follow along with downloading packages from unofficial or potentially malicious sources. Always include the raw HTTP or TCP requests alongside any script. This ensures we can validate the finding even if we cannot run the script ourselves.
Video PoCs and screenshots
Video proofs-of-concept are encouraged, and some programs now require them. Regardless, always attach screenshots as evidence supporting your report in case your reported vulnerability becomes unreproducible after changes. Having evidence at hand matters and ensures your report remains valid.
4. Impact
The impact section is where you explain what an attacker could realistically achieve by exploiting the vulnerability. Keep it short, specific, and to the point, while always describing the actual consequence instead of hypothetical scenarios that are entirely speculative in nature.
If it's a reflected XSS, explain what an attacker can do with it and provide the necessary evidence to back up your claim. Can the attacker fetch sensitive session cookies, perform actions on behalf of the victim, or redirect to an external website? If it's an IDOR, explain what data is exposed or what actions can be taken on behalf of another user.
It is essential to note that you should never overestimate the impact. Avoid including attack scenarios that are speculative in nature. Your submission's severity is mostly determined by the evidence provided. If you cannot prove it, it's best to gather more information before submitting a report.
Important! Most program rules prohibit disruptive testing. That's why, in some cases, we rather want you not to go forward with fully exploiting a SQL injection or DoS vulnerability. In such cases, we consider the potential impact instead of the evidence provided to avoid any disruption. Do note that the company is allowed to adjust the severity after it gathers the necessary information around the identified vulnerability.
5. Severity
The general rule is always to be honest. Try to manually select the severity based on the available CVSS v3.1 or v4 metrics and ensure that it accurately reflects the vulnerability based on the evidence you've provided. If you're unsure, refer to the program's severity guidelines or the CVSS (Common Vulnerability Scoring System) score.
Repeatedly submitting Medium or Low findings as Critical or Exceptional does not increase your bounty, nor will it speed up the triage times. In fact, the reverse is true, it actually increases your time to triage and reflects an unprofessional image. On the contrary, researchers who submit accurate severities build trust with triage teams and programs, which benefits them in the long run.
Always read the program description, some program's explicitly mention pre-set severities for certain vulnerability types, ensure you take such conditions and exceptions into account too.
Also consider our 'Rulings and exceptions' in our Triage Standards, where we list several vulnerability types with pre-set severities.
6. Attachments
Include everything the triager needs to validate your submission in one place. That means your proof-of-concept scripts, all screenshots referenced in the steps, video evidence where applicable, and raw HTTP requests.
Do not upload evidence to third-party platforms like YouTube, Dropbox, Google Drive, Mega.nz, or similar third-party file sharing services. Uploading potentially sensitive information to such services is against our Community Code of Conduct. When in doubt, ask us before submitting.
Conclusion
Report writing may not be the most exciting part of bug bounty, but it directly determines how quickly your findings get triaged and rewarded. In this article, we've covered each section of the report form and outlined what makes a submission easy to process, from a clean title format to validated reproduction steps and accurate severity assessments.