Hola Friends,

I've been seeing a steady wave of complaints about the same types of issues and I wanted to provide this quick PSA to say that if you are starting your journey into bug bounty hunting (like I am) and your reports are getting rejected, it might just be you!!

And I'm saying this as someone who has mastered the art of failing forward in their career, and been kicked around more times than I care. Learning the hard way is not always the best way, but it is effective.

tl;dr: If your report gets rejected, it will be because: you wrote a report so bad it will serve as lining in a bird cage, or you aren't presenting sufficient risk and the client is not convinced .. therefore it is "N/A" or "Informational."

Below are the top three most consistent issues I've seen people complain about. Read carefully and learn so you don't have do keep hitting your head against the wall hoping for the wall to get softer.

Scenario 1 — The much-hated "Not Applicable" response!

There you are, on the program, working hard at performing reconnaissance of the target and ❗️BOOM ❗️you swear you found something interesting. You write it up, submit it, and you get an email with words to the effect of, "Thank you for your submission. We have determined that this issue does not pose an actionable impact and is not applicable to the program."

Your immediate reaction .. rage 😡. You want to scream at the entire triage process, the person who evaluated your report, and everything within eye sight. You run to reddit and rage-post on how unfair you were treated, and how crappy the triage process is, without seeing the obvious flaws in your report:

• You merely performed reconnaissance and barely discovered something. Nothing further was done.
• You failed to properly document the issue. Your description is bad, your steps to reproduce are worse.
• You never established proper impact.

Recommendation — Don't let your ego write the report. Double (even triple) check your work before submission.

Scenario 2 —The equally loathed "Informational" response!

It's 3am and you are locked in on the vulnerability. It is a juicy IDOR (Indirect Object Reference) where you were able to gain access to someone else's cart information by changing the easily guessable cart_idwhile performing checkout as a guest user. Surely this is going to get you paid, right?

You compose the report, with sufficient evidence and concise steps. It's immaculate and well-written. You submit hoping it lands you some serious loot. Then you get the program's triage response: "Thank you for your submission. We have determined that this bug does not pose an actionable impact and we do not see it as an immediate threat. It will be closed as Informational."

That feeling of 😃 elation is now 😡 rage!! You know you want to scream at the person, or process, that evaluated your report. You submit an appeal and patiently wait for their reply, not realizing there are a couple of points you might not be aware of:

• The issue you've presented has a low impact because it happens as the user is a guest, and the information disclosed is not sensitive.
• The risk to the business is minimal because no actual user is going to go through the effort of guessing someone else's cart_id. And even if they did, all they can see is another guest user's items. So long as the payment information remains securely hidden (which you didn't check), there's no cause for concern.

Recommendation — When you do submit a report, learn to detach. An informational result means you did everything right but the outcome is outside of your control. Don't quit!!

Scenario 3 — The downgraded response!

You are on a high-value program and you've discovered a rate-limiting issue with their authentication form. You've validated it is within scope and you've confirmed you aren't causing any systemic disruptions. You've tested and re-tested to ensure there is enough evidence to validate your finding. You write the report, provide the evidence, and show demonstrable (not theoretical) impact.

You submit hoping it lands you some serious loot. Then you get the program's triage response: "Thank you for your submission. We have determined that this issue does not rise to the level of a critical issue and will be downgraded accordingly. Thank you for your time and effort …"

While not a completely bad outcome, you find yourself a bit disappointed by the result. You know, based on experience, that a rate-limiting issue taken to it's ultimate conclusion can lead to major issues, not limited to full system compromise. Yet, for whatever reason, the triage rubric has declared this to be a lesser priority. Why?

• You were testing in their staging environment, where the security controls are more relaxed.
• You were using tools and techniques that a common user would not employ when interacting with the system.

Recommendation — Don't let perfect be the enemy of good.

Conclusion

Whew!! We've covered a lot of ground with these three recurring scenarios. Let me take a few minutes to offer these keys to a good bug report for bug bounties:

1. Your report has to be clearly written. No AI slop or poor grammar .. honestly, this has to be the no. 1 reason your reports are getting rejected as "N/A"
2. Your report has to demonstrate IMPACT .. not a theoretical scenario:

Instead of "An attacker could …," make it read "An attacker can …" — and show this with proper screenshots and/or video evidence. For example: "The attacker can compromise the system by uploading an .svg file containing a malicious payload, like the one shown in the screenshot below" reads a lot better than, "An attacker could upload any file that might cause an issue to the system."

3. The steps have to be clear and concise. By saying, "verify {x}" you are, in essence, asking the reader to perform an implicit act (I have to bake a cake) to arrive at an explicit outcome (verify the cake is baked). Not good!! Steps should look something like:

* Launch the site in any browser * Log in with the credentials provided * Log out and notice the url_redirect parameter displayed * Modify the parameter by replacing the redirect URL with the attacker site

4. The POC has to substantiate the finding. Don't just make sh** up (excuse my language)

5. Screenshots or videos must serve to "show" the vulnerability … Or it didn't happen

Follow these points and you should be ok. If you write a solid report, you eliminate the excuse that it was the triage process.

Remember your report is doing two things:

• Demonstrating your skill and expertise. Poorly written report == bad tester. Ask me how I know!!
• Demonstrating impact (and risk) to the business. A bad report wastes everyone's time.

If you are new, please pay attention to these points and do better! Keep putting in the effort, it will eventually pay off.

Feel free to comment if you agree or disagree, or have something you'd like to share.

ciao for now