How to Write a Professional Vulnerability Report

Finding a vulnerability is only half of the work.

The other half is communicating it clearly.

A professional vulnerability report should allow the reader to answer five questions:

  1. What is the issue?
  2. Where is it located?
  3. How can we reproduce it?
  4. What is the impact?
  5. How should we fix it?

If the report cannot answer those questions, the finding may be technically correct but operationally weak.

Image: Type: Context. Mô tả: “A clean vulnerability report layout showing Summary, Affected Endpoint, Steps to Reproduce, Evidence, Impact, Remediation, and References.” caption: “A strong report is structured for developers, managers, and security teams.”

Context

A vulnerability report has multiple audiences.

Developers need:

  • Affected endpoint
  • Reproduction steps
  • Expected vs actual behavior
  • Technical root cause
  • Remediation guidance

Managers need:

  • Business impact
  • Severity
  • Affected users or data
  • Priority
  • Risk explanation

Security teams need:

  • Evidence
  • Scope
  • Exploitability
  • Detection opportunities
  • Verification steps

A good report serves all three without becoming confusing.

Basic Report Structure

Use this structure for most web findings:

Title
Severity
Summary
Affected Asset
Affected Endpoint
Prerequisites
Steps to Reproduce
Evidence
Impact
Root Cause
Remediation
Verification Steps
References

Not every finding needs every section, but this structure keeps the report complete.

1. Title

The title should be specific.

Weak title:

Access Control Issue

Better title:

Broken Object Level Authorization Allows Users to Access Other Users' Invoices

A good title includes:

  • Vulnerability class
  • Affected feature
  • Main impact

Examples:

Stored XSS in Profile Display Name Allows JavaScript Execution for Other Users
Password Reset Token Reuse Allows Account Recovery Link Replay
Missing Authorization on Invoice API Allows Cross-User Data Access

2. Severity

Severity should reflect both technical exploitability and business impact.

Do not assign severity only because a tool says so.

Consider:

  • Authentication required or not
  • User interaction required or not
  • Data sensitivity
  • Number of affected users
  • Privilege required
  • Business function affected
  • Whether the issue can be chained
  • Whether exploitation is reliable

CVSS can help standardize scoring, but the explanation matters more than the number.

3. Summary

The summary should be short and clear.

Example:

The invoice API does not enforce object-level authorization. A regular user can change the invoice ID in the URL and retrieve invoices belonging to other users. This may expose customer billing data, invoice history, and personally identifiable information.

A strong summary avoids unnecessary jargon.

4. Affected Asset and Endpoint

Be precise.

Example:

Asset: https://app.example.com
Endpoint: GET /api/v1/invoices/{invoice_id}
Role: Authenticated regular user
Environment: Production

If the issue affects multiple endpoints, list them clearly.

5. Prerequisites

State what is needed to reproduce the issue.

Examples:

- Two regular test accounts
- User A owns invoice 1001
- User B owns invoice 2001
- Valid session token for User A

This prevents confusion during triage.

6. Steps to Reproduce

Steps should be deterministic.

Weak steps:

Login and change the ID.

Better steps:

1. Log in as User A.
2. Open the invoice page for invoice 1001.
3. Capture the request in Burp Suite.
4. Change the invoice ID from 1001 to 2001, which belongs to User B.
5. Send the modified request.
6. Observe that the API returns User B's invoice data.

Each step should move the reader closer to reproduction.

Image: Type: Test case. Mô tả: “A sanitized Burp Repeater screenshot showing an original request and modified request, with sensitive values redacted.” caption: “Good evidence should be reproducible, sanitized, and tied to clear steps.”

7. Evidence

Evidence should prove the issue without exposing unnecessary sensitive data.

Include:

  • HTTP request
  • HTTP response
  • Screenshot
  • Account context
  • Object ownership context
  • Redacted tokens or secrets
  • Response difference

Redact:

  • Access tokens
  • Cookies
  • Passwords
  • API keys
  • Personal data not needed for proof
  • Customer secrets

Evidence should be minimal but sufficient.

8. Impact

Impact is where many reports become weak.

Do not write only:

An attacker can access sensitive data.

Explain what kind of data, whose data, and why it matters.

Better:

An authenticated user can retrieve invoices belonging to other users. This may expose customer names, billing addresses, purchased services, invoice amounts, tax information, and payment-related metadata. In a multi-tenant environment, this breaks tenant isolation and may create regulatory and contractual risk.

Impact should connect technical behavior to business risk.

9. Root Cause

Root cause explains why the vulnerability exists.

Example:

The backend retrieves invoices by invoice_id but does not verify that the invoice belongs to the authenticated user's account or organization. Authorization appears to be enforced in the frontend navigation only, not in the API endpoint itself.

Root cause helps developers fix the design, not only the symptom.

10. Remediation

Remediation should be practical.

Example:

Enforce object-level authorization on the server side for every invoice access. The invoice lookup should be scoped to the authenticated user's account or organization. If the invoice does not belong to the caller, the API should return an authorization failure and log the event for monitoring.

Better remediation includes:

  • Server-side control
  • Where to apply it
  • Expected behavior
  • Regression test idea

Avoid vague advice like:

Implement better security.

11. Verification Steps

Help the team confirm the fix.

Example:

1. Log in as User A.
2. Attempt to request User B's invoice ID.
3. Confirm the API returns 403 Forbidden or equivalent access denial.
4. Confirm no invoice data appears in the response.
5. Repeat the test across all invoice-related endpoints.

Verification steps reduce back-and-forth after remediation.

Professional Report Template

Title:
Severity:
Affected Asset:
Affected Endpoint:
Affected Role:

Summary:

Steps to Reproduce:
1.
2.
3.

Evidence:

Impact:

Root Cause:

Remediation:

Verification Steps:

References:

Common Mistakes

Mistake 1: No Business Impact

A report that only says “IDOR exists” is incomplete.

Explain what the attacker can access or change.

Mistake 2: Unclear Reproduction

If developers cannot reproduce the issue, the fix will be delayed.

Use exact endpoints, roles, and steps.

Mistake 3: Too Much Sensitive Data

Do not paste unnecessary personal data, full tokens, passwords, or secrets.

Proof should be controlled and sanitized.

Mistake 4: Generic Remediation

Generic remediation is less useful.

Tie remediation to the vulnerable feature.

Mistake 5: Overstated Severity

Exaggerated severity reduces trust.

Be firm, but accurate.

Final Checklist

Before submitting a report, check:

[ ] Title is specific
[ ] Severity has a clear rationale
[ ] Affected endpoint is listed
[ ] Reproduction steps are deterministic
[ ] Evidence is sanitized
[ ] Impact is business-relevant
[ ] Root cause is explained
[ ] Remediation is actionable
[ ] Verification steps are included
[ ] References are relevant

References

CTA

KevinSec provides web pentest reports that are clear, reproducible, and remediation-focused. If your team needs findings that developers can fix and managers can prioritize, a professional security report is part of the value, not just an attachment at the end.