High-quality reports help security teams quickly understand and triage vulnerabilities. A well-structured report improves response time and increases the likelihood of a positive outcome.

It's best to be comprehensive yet concise, as security teams need to have all the details required to verify and validate your report. We recommend you provide enough information to:

Outline the bug
Reproduce the bug
Assess the coverage the bug applies to
Provide additional related logs or information

Note: Before submitting, verify that your issue hasn’t already been reported and that it falls within the program’s scope.

What Makes a Quality Report?

A quality report provides clear, detailed, and actionable information about a vulnerability. It should include:

A clear and concise title – Summarize the vulnerability in a way that helps security teams quickly understand the issue.
Detailed steps to reproduce – Provide a step-by-step guide that allows the security team to replicate the issue easily. Screenshots, screen recordings, and code snippets are a great addition to improve clarity.
Impact assessment – Explain the potential consequences of the vulnerability, including how an attacker could exploit it and what damage it could cause.
Remediation suggestions (if possible) – While not required, including suggestions for fixing the issue can be helpful.

Writing a Strong Report

1. Title

A good title quickly conveys the nature of the vulnerability.

Example:

Weak: XSS in web app

Better: Stored XSS in user profile field allows script execution on profile view.

2. Steps to Reproduce

Provide clear, numbered steps. Include necessary details like URLs, affected parameters, and user roles required to trigger the vulnerability.

Example:

Log in as a regular user.
Navigate to the profile settings page at https://example.com/settings/profile.
Insert <script>alert('XSS')</script> into the "About Me" field and save.
Log out and view the profile as another user.
The script executes on page load.

3. Expected vs. Actual Behavior

Clearly state what should happen versus what actually happens.

Example:

Expected: The profile field should sanitize input to prevent script execution.
Actual: The script executes when another user views the profile.

4. Impact

Explain the security implications.

Example: An attacker could store malicious JavaScript in their profile, causing code execution in the browser of any user who views it. This could lead to session hijacking, phishing, or other attacks.

5. Supporting Material

Enhance your report with:

Screenshots of the issue in action.
Video recordings demonstrating the exploit.
Code snippets of payloads used.

Common Mistakes to Avoid

Vague reports – Avoid general statements like "There’s an XSS vulnerability." Provide detailed reproduction steps.
Lack of impact explanation – Explain why the issue matters.
Poor formatting – Use clear structure, headings, and bullet points to improve readability.
Overloading with unnecessary details – Focus on what’s relevant to the security team.

Final Checks Before Submission

Before submitting, review your report:

Can the vulnerability be easily reproduced with the provided steps?
Is the impact clearly explained?
Have you included supporting materials where necessary?
Is all logging and code in the proper format?
- Use code blocks and markdown language.

A well-structured, detailed report helps security teams address vulnerabilities faster and increases the likelihood of a positive response.