Bug Bounty Impact Writing Guide for Triage

Bug Bounty Impact Writing Guide for Triage

Impact writing is not the same as writing reproduction steps. Reproduction tells triage what the application did. Impact explains what an attacker gains, which user or system bears the loss, and what conditions stand between the bug and that outcome.

“This leads to account takeover” is not impact analysis. It is a conclusion. Show the bridge.

Start with the broken boundary

Name the attacker and the asset in one sentence: “An authenticated workspace member can download invoice PDFs belonging to another workspace by changing invoiceId.” That line carries more information than “Critical IDOR.”

Follow with the proven capability. Did you read one planted record, modify a reversible field, mint a token, or execute script in an administrator's origin? Keep observed facts separate from plausible escalation.

A useful structure is:

• Proven: what your controlled test demonstrated
• Required: account, role, victim action, timing, or identifier knowledge
• Reach: one user, any tenant, public internet, or internal staff
• Consequence: confidentiality, integrity, availability, or financial abuse
• Limit: controls that reduce exploitation

Limits increase credibility. If IDs are random and must be known, say so. If the victim must approve an OAuth prompt, show exactly what the prompt reveals.

Use severity language carefully

Critical should describe catastrophic reach or control, not your excitement. Unauthenticated remote code execution, broad authentication bypass, or mass access to highly sensitive records may justify it. A single-user stored XSS requiring an administrator view can be serious, but victim role, interaction, CSP, and available actions shape the rating.

Avoid stacking every imaginable chain: “could lead to phishing, malware, ransomware, data breach, and reputational damage.” Pick the nearest credible consequence and support it with product behavior.

CVSS can help communicate attack vector, privileges, interaction, scope, and impact, yet many bounty programs use their own taxonomy. Explain the facts first. A disputed score should not sink a clear report.

Convert technical primitives into product loss

SSRF impact is not “the server makes a request.” State whether it reaches an internal health page, cloud metadata, or only your public listener. XSS impact is not “JavaScript executes.” State whose origin, which victim, and whether sensitive actions require re-authentication. Rate-limit bypass impact depends on the protected action: extra search requests and unlimited OTP attempts are not peers.

Use quantities you can defend. If one request returns 100 records and pagination exposes 20 pages from your two test tenants, describe that pattern. Do not claim millions of records without evidence or a public dataset size.

Give triage a safe decision path

End the impact section with the shortest attack narrative:

1. Attacker obtains a normal member account.
2. Attacker changes one object identifier to a victim workspace ID.
3. Server returns the victim's private invoice without an authorization check.
4. The same request pattern applies to other invoice IDs.

Then state what you deliberately did not test. “I stopped after retrieving a canary PDF from my second account and did not access customer invoices.” This tells the team the ceiling may be higher without making an unsupported claim.

Recommended remediation belongs after impact. Keep it tied to the cause: enforce object authorization using the authenticated tenant, not merely “sanitize input.”

Strong impact language is concrete, bounded, and slightly boring. That is a compliment. OWASP's authorization material gives shared vocabulary for broken boundaries; your product-specific evidence tells triage how much the boundary matters here.