It's not stored. It needs user interaction. It usually shows up as a harmless-looking alert.

So it gets labeled low severity, pushed down the backlog, or ignored entirely.

The problem is that this mindset focuses on how the bug is delivered instead of what actually happens once it runs.

Why reflected XSS looks harmless on the surface

Most reflected XSS issues live in very ordinary parts of an application.

Search pages Filters Error messages Redirect endpoints

You'll often see something like this in a template:

<p>Search results for: {{ query }}</p>

If query comes straight from the URL and isn't properly escaped, that's already enough to trigger reflected XSS.

Because nothing is stored and nothing visibly breaks, it feels low impact. There's no database pollution, no persistent payload, no immediate damage.

That's why it gets dismissed.

What changes when a real user clicks the link

Once a user opens a reflected XSS link, the browser does not treat it as temporary or low risk.

It treats it as trusted JavaScript.

Same domain Same origin Same session

If the response ends up like this:

<p>Search results for: <script>/* injected code */</script></p>

The browser executes it without hesitation.

Stored or reflected does not matter to the browser. Execution is execution.

Why "user interaction required" is not a defense

Requiring a click is not protection.

Users click links constantly: Emails Messaging apps Ads QR codes Shortened URLs

If the link points to a real domain with a valid certificate, users trust it. That trust is exactly what makes reflected XSS effective.

The payload is delivered through a domain the attacker doesn't own, but the user already trusts.

What injected JavaScript can actually do

Once JavaScript runs inside the page, its capabilities are not limited.

It can read the DOM:

const content = document.body.innerText;

It can hook into input fields:

document.addEventListener("input", e => {
  if (e.target.tagName === "INPUT") {
    // capture user input
  }
});

It can observe user behavior silently, without breaking anything or showing visible signs.

Cookies are not the whole story

If cookies are not HttpOnly, they can be read directly:

const cookies = document.cookie;

If cookies are HttpOnly, the script can still act as the user.

For example, sending authenticated requests:

fetch("/account/settings", {
  method: "POST",
  credentials: "include",
  body: JSON.stringify({ setting: "changed" })
});

No session theft is required. The browser automatically includes everything because the request comes from the same origin.

Keylogging without malware

Reflected XSS can quietly capture keystrokes:

document.addEventListener("keydown", e => {
  // record keystrokes
});

This includes: Passwords Messages Search terms One-time codes

There are no popups, no visual glitches, and no obvious indicators that anything is wrong.

Everything looks normal to both the user and the server.

Phishing without leaving the site

Instead of redirecting users to an external phishing page, reflected XSS allows attackers to modify the page itself.

For example:

document.body.innerHTML = `
  <h2>Session expired</h2>
  <form>
    <input type="password" placeholder="Password">
    <button>Login</button>
  </form>
`;

The URL stays correct. The certificate remains valid.

This is far more convincing than external phishing pages.

Why reflected XSS keeps being deprioritized

It isn't flashy. It isn't persistent. It doesn't feel urgent.

So it keeps getting marked low risk.

But attackers don't need persistence. They need execution once.

One successful click is enough.

The real issue

If an application reflects user input and executes it in the browser, control is briefly handed to whoever crafted that input.

It does not matter whether the payload is stored or reflected.

The browser executes it either way.

Reflected XSS is not ignored because it is harmless. It is ignored because its impact is quiet.

And quiet vulnerabilities are often the most dangerous ones.

Thanks for reading :)