How to Write a Bug Report That Won’t Get Marked “Informative”

I lost a bounty once. Not because the bug wasn't real. Because my report was garbage.

I was so excited about finding something that I rushed the write-up. Few sentences. One screenshot. Hit send.

Three days later: "Informative. Thanks anyway."

I was furious. Then I read my own report and realized… they were right. I didn't explain the impact. Didn't show the steps clearly. Didn't prove it was actually a security issue.

That hurt. But it taught me something important.

Finding the bug is half the battle. Writing it up is the other half.

– -

What I Was Doing Wrong

I thought good reports needed to be short. Get to the point. No fluff.

Turns out short isn't helpful. It's lazy.

A triager reads your report in two minutes. If they can't understand the bug in that time, they mark it low or informative and move on.

They're not trying to be mean. They have 50 other reports waiting. Yours needs to be obvious.

– -

The Format That Works For Me

I use the same template every time now. Nothing fancy. Just clear.

Title – Short but specific. Not "IDOR found" but "IDOR on /api/profile endpoint allows viewing any user's email and phone number"

Description – One sentence saying what the bug is and why it matters.

Steps to reproduce – Numbered list. Start from the beginning. Assume they know nothing. "1. Login as test user 2. Go to profile page 3. Open dev tools…"

Proof – Screenshot or video. Highlight the important part with a red box. Don't make them search.

Impact – What can an attacker actually do? Not "bad things" but "steal user data" or "take over accounts" or "bypass payment."

Suggested fix – Optional but appreciated. Shows you're not just complaining.

– -

The One Thing That Made The Biggest Difference

I stopped assuming triagers know the product.

They don't. They might be reviewing reports for ten different programs that day. They don't know your target's special quirks.

So I started over-explaining. "Click the profile icon in the top right corner" instead of "go to profile." "Enter test@example.com as the email" instead of "enter an email."

Feels dumb to write. But it works. No confusion. No back and forth. Faster payout.

– -

A Real Example

Here's a short version of a report that got me paid.

Title: Stored XSS in comment section via image filename

Description: Uploading an image with a malicious filename triggers XSS on the comments page.

Steps:

1. Log in as any user
2. 2. Go to any post with comments enabled
3. 3. Create a file named .jpg on your computer
4. 4. Upload it as a comment attachment
5. 5. View the comment thread

Proof: [screenshot showing alert popup]

Impact: Attacker can steal cookies, redirect users, or deface the page.

Fix: Sanitize filenames before rendering.

That's it. Nothing fancy. But the triager replicated it in two minutes and approved it in one day.

– -

Mistakes I Made That You Should Avoid

No proof. "Trust me I found a bug" doesn't work. Ever.

Vague steps. "Click around until you see it" – no. Be exact.

No impact. "This is bad" isn't impact. "This exposes private messages" is impact.

Too many attachments. Five screenshots of the same thing. Pick the best one. Maybe two.

Arguing with triagers. If they mark it duplicate or informative, ask politely why. Sometimes they're wrong. Sometimes you are. Being rude gets you nowhere.

– -

The Secret That Took Me Too Long To Learn

Write your report like you're explaining the bug to a non-technical friend who needs to approve payment.

Clear. Step by step. Proof at the end.

If they can't understand it in two minutes, rewrite it.

– -

To the person who asked for this topic – thanks. This one was for you.

If this saved you from losing a bounty, clap and follow.