Writing Good Reports

A good report is what separates a bounty from a duplicate or a N/A. Good reports build reputation and get private invites.

Title: [Bug Type] on [Feature/Endpoint] leads to [Impact]

Examples:

• “Stored XSS in profile bio via unsanitized <script> tag leads to account takeover”
• “CSRF on email change endpoint allows attacker to take over any account”
• “Open Redirect at /oauth/callback chains with OAuth to steal access tokens”

1. Title – descriptive, specific, includes impact
2. Severity – Critical / High / Medium / Low with justification
3. Summary – 2-3 sentences: what is the bug, where is it, what can an attacker do
4. Steps to Reproduce – numbered, exact, reproducible from scratch
5. Proof of Concept – working PoC code, screenshots, or video
6. Impact – concrete damage an attacker can cause
7. Remediation – suggested fix

Be so precise that a developer who has never seen this bug can reproduce it on the first try:

1. Numbered steps
2. Exact URLs
3. Exact payloads
4. Expected vs actual result
5. What account types/permissions are needed

PoC or GTFO. Show impact with:

• Working exploit code (JavaScript, HTML, curl commands)
• Screenshot of data exfiltrated or action performed
• Video walkthrough for complex chains
• Clear before/after showing the exploit succeeded

• No PoC – “this could theoretically…”
• Impact too vague – “attacker could use this for phishing”
• Steps not reproducible – missing account setup, missing exact URL
• Out of scope target
• Already known / duplicate
• Requires unlikely user interaction

• Respond promptly to triager questions
• Be helpful, not adversarial, when they push back
• If they disagree on severity, explain your reasoning with evidence
• Treat it as a collaboration – they want to fix bugs too
• Good reputation = private program invites = less competition

• Bug Chaining & Escalation
• Picking a Program
• Methodology Index