Readiness guide · Cross-Site Scripting

Why XSS bug-bounty reports get marked N/A — and how to prove real impact

alert(1) proves script execution. It does not prove impact — the reports that get paid demonstrate what the execution lets you steal or do.

← All readiness guides

Why triagers mark it N/A

• Reflection without execution. “My input appears in the response” is not XSS until it runs. Encoded or context-broken reflection is a false positive.
• alert(1) with no impact. Execution in a throwaway context, self-XSS, or a payload that only fires for the attacker doesn’t demonstrate victim harm.
• No exfiltration. Claiming “an attacker could steal the session” without actually exfiltrating a token or performing an authenticated action is a theory.
• Requires unrealistic conditions. Self-XSS, or an attack needing the victim to paste a payload into their own console, is routinely rejected.

What proof actually looks like

Turn execution into theft or action: craft a link or payload that, when a victim opens it, exfiltrates the victim’s token (or performs an authenticated action as them) to a place you control. Show the crafted input, the sink it reaches, and the stolen value arriving — proving a real victim loses something, not that a script can run.

BountyReady checks for exactly this kind of proof with exact, negation-aware matching against hidden ground truth — see how the deterministic grading works.

Before you submit — checklist

• Does the payload execute in the victim’s context (not just reflect, not self-XSS)?
• Does it exfiltrate a real value (a token) or perform an authenticated action as the victim?
• Is the delivery realistic (a link/parameter a victim would actually open)?
• Did you capture the payload-to-sink-to-stolen-value chain as evidence?
• Is the impact stated as theft/ATO, not “input is reflected”?

Other readiness guides

• IDOR / BOLA — readiness guide
• Server-Side Request Forgery — readiness guide
• SQL Injection — readiness guide
• Authentication / JWT bypass — readiness guide