Cross-site scripting is the vulnerability everyone has heard of and few can explain clearly. The confusion is that "XSS" is really three different bugs. Once you separate them, testing each is straightforward.
> Test only applications you own or are authorized to test.
The Core Idea
XSS happens when an app takes input and renders it as code instead of data. Your
If the search results page echoes q without encoding it, the script runs. It's "reflected" because it isn't stored — the victim has to click a crafted link.
Type 2: Stored XSS
The payload is saved — in a comment, profile bio, or product review — and runs for everyone who views that page. This is the dangerous one: no link needed, it fires for every visitor. I test it by putting payloads in any field that gets displayed back later.
Type 3: DOM-Based XSS
No server round-trip — client-side JavaScript takes something from the URL or page and writes it into the DOM unsafely:
document.getElementById('out').innerHTML = location.hash;
The fix and the bug both live entirely in the browser. You find it by reading the JS, not the server response.
A Safe Test Payload
alert(1) proves execution without doing harm. Better for confirming context:
If document.domain pops, you've proven script execution in that origin.
The Underlying Fix
All three come down to one rule: encode output for the context it lands in. HTML context, attribute context, and JavaScript context each need different encoding. Understanding where the input gets rendered is what separates "I typed a payload" from "I understand the bug."