Post cover image

September 9, 2026

Cross-Site Scripting (XSS): When User Input Becomes Code

If you have been learning web hacking for a while, you have probably seen this payload everywhere:

By 4zer7y

12 min read

<scrip>alert(1)</scrip>

(I misspelled "script" on purpose because it seems Medium has a validation check that prevents XSS from running, haha. )

But, okay, you have probably seen that payload, and maybe your first reaction was:

Okay… so I can make a popup appear. Why should I care?

That is actually a pretty reasonable question.

The popup itself is almost useless. What matters is why the browser executed it in the first place.

If you can make JavaScript controlled by you execute inside somebody else's session on a legitimate website, the alert box is just the proof. The real vulnerability is that the website has accidentally allowed your input to become trusted code.

That is Cross-Site Scripting, or XSS.

And despite being one of the oldest web vulnerabilities around, XSS is definitely not dead.

So, What Exactly Is XSS?

Let's start with the simplest possible definition:

XSS happens when attacker-controlled data reaches a web page in a way that causes the browser to interpret that data as executable code instead of plain text.

Imagine a website has a search page:

https://example.com/search?q=hacking

And the server generates:

<h2>Search results for: hacking</h2>

Nothing strange there.

But imagine the backend is essentially doing something like:

<h2>Search results for: USER_INPUT</h2>

without properly handling that input.

Now someone sends:

<scrip>alert(1)</scrip>

and the server returns:

<h2>
Search results for:
<scrip>alert(1)</scrip>
</h2>

The browser does not know that the <scrip>tag came from an attacker.

It just sees HTML.

So it executes it.

And that is the important part.

The application thought:

This is user data.

The browser thought:

This is JavaScript.

That confusion between data and code is the heart of XSS.

The Mental Model Behind XSS

When testing for XSS, I find this mental model much more useful than memorizing dozens of payloads:

ATTACKER INPUT
      ↓
APPLICATION
      ↓
HTML / JavaScript / DOM
      ↓
BROWSER PARSES IT
      ↓
ATTACKER-CONTROLLED CODE EXECUTES

Your job as a tester is basically to figure out:

Can I control some data?
        ↓
Where does that data go?
        ↓
How does the browser interpret it?
        ↓
Can I transform that data into executable code?

That's XSS hunting in a nutshell.

Why the Browser's Trust Matters

This is where XSS becomes much more interesting.

Browsers have an important security concept called the Same-Origin Policy.

Very roughly, JavaScript running on:

evil.example

should not simply be able to access information from:

bank.example

Those are different origins.

Normally:

evil.example
     ↓
JavaScript
     ↓
bank.example
BLOCKED

But XSS changes the situation.

Instead of running JavaScript from the attacker's site, we convince the vulnerable website itself to execute attacker-controlled JavaScript.

Now we have:

bank.example
     ↓
Injected JavaScript
     ↓
Victim's browser

From the browser's perspective, that JavaScript is running inside bank.example.

That's the security boundary XSS breaks.

PortSwigger describes the core consequence in similar terms: XSS can bypass the browser's same-origin isolation and potentially allow an attacker to perform actions or access data available to the affected user.

So the vulnerability isn't really I made JavaScript run, actually, It is I made my JavaScript run with the trust and privileges of your application.

Much more interesting.

There Are Three Main Types of XSS

You will usually encounter three big categories:

Reflected XSS
Stored XSS
DOM-Based XSS

There are also variations such as blind XSS and self-XSS, which we will talk about later.

Let's go through the important ones.

1. Reflected XSS

Reflected XSS happens when your input arrives in an HTTP request and the server immediately sends it back inside the response without safely encoding it.

Imagine this URL:

https://example.com/search?q=coffee

The server responds:

<p>You searched for: coffee</p>

Now replace coffee with something interesting:

<scrip>alert(1)</scrip>

If the application responds with:

<p>You searched for:<scrip>alert(1)</scrip></p>

and the browser executes it, we have reflected XSS.

The attack flow looks like this:

Attacker creates malicious URL
            ↓
Victim clicks URL
            ↓
Request reaches vulnerable website
            ↓
Website reflects malicious input
            ↓
Browser executes it

The word reflected makes sense now: the payload arrives in the request and gets reflected straight back into the response.

Where should you look?

Typical places include:

Search fields
Error messages
GET parameters
POST parameters
Redirect parameters
Filtering options
Tracking parameters
HTTP headers

Whenever you see user-controlled data appearing back inside the HTML response, it deserves attention.

2. Stored XSS

Stored XSS is where things start getting much more serious.

Instead of the payload being immediately reflected, the application stores it somewhere.

Usually a database.

Imagine a comment system.

You submit:

Nice article!

The server stores it:

Database
└── comment = "Nice article!"

Later, somebody opens the page and receives:

<div class="comment">
    Nice article!
</div>

Now imagine the application allows this to be stored:

<scrip>alert(1)</scrip>

The database now contains:

Database
└── comment = "<scrip>alert(1)</scrip>"

Every time someone opens that page:

Database
      ↓
Application
      ↓
Victim's browser
      ↓
JavaScript executes

That is stored XSS.

PortSwigger also calls this persistent or second-order XSS because the malicious data is stored and becomes dangerous when it is later rendered.

And here's why this can be worse than reflected XSS:

With reflected XSS, you often need to convince someone to click a crafted link.

With stored XSS, you might just plant the payload and wait.

Stored XSS Can Become Especially Dangerous

Think about a support ticket system.

A normal user submits:

My account isn't working.

A support administrator later opens the ticket.

Now imagine the message contains malicious HTML or JavaScript and the application renders it unsafely.

The flow becomes:

Low-privileged attacker
        ↓
Support ticket
        ↓
Database
        ↓
Administrator opens ticket
        ↓
JavaScript executes
        ↓
Admin privileges become relevant

Suddenly the impact of the XSS depends on the permissions of the person viewing it.

That can be a very big difference.

3. DOM-Based XSS

DOM XSS is slightly different and, in my opinion, much more interesting once you start reading JavaScript during pentests.

Here the vulnerability can live completely inside client-side JavaScript.

Suppose the page contains:

const search = new URLSearchParams(location.search).get("q");
document.getElementById("result").innerHTML = search;

You visit:

https://example.com/?q=hello

JavaScript reads:

hello

and inserts it into:

innerHTML

The important data flow is:

location.search
       ↓
search
       ↓
innerHTML
       ↓
HTML parser

If attacker-controlled input reaches a dangerous operation like innerHTML, DOM XSS may become possible. PortSwigger describes DOM XSS exactly in terms of attacker-controlled sources reaching dangerous sinks.

This introduces two concepts worth remembering.

Sources and Sinks

A source is where potentially attacker-controlled information enters JavaScript.

Examples:

location.search
location.hash
document.URL
document.referrer
window.name
postMessage()

A sink is somewhere that data becomes dangerous.

Examples include:

innerHTML
outerHTML
document.write()
eval()

So during JavaScript analysis, you're basically looking for:

SOURCE
   ↓
data transformations
   ↓
SINK

For example:

let username = location.hash.substring(1);
profile.innerHTML = username;

Your brain should immediately see:

location.hash
      ↓
username
      ↓
innerHTML

Interesting.

Now the question becomes whether we can control that source strongly enough to make the browser interpret our input as code.

XSS Is Context Dependent

This is one of the most important things to understand.

Finding your input reflected in the response doesn't automatically mean XSS.

Where the input lands matters.

For example:

<div>INPUT</div>

is different from:

<input value="INPUT">

which is different from:

let username = "INPUT";

which is different from:

<a href="INPUT">Click here</a>

Those are completely different parsing contexts.

And different contexts require different approaches.

Example: HTML Context

Suppose your input lands here:

<div>
USER_INPUT
</div>

Before even thinking about JavaScript, I like using something harmless:

<b>XSS_TEST</b>

If the browser shows:

XSS_TEST

in bold, something important just happened.

Your input was not treated purely as text.

The browser interpreted it as HTML.

That does not yet prove JavaScript execution.

But you just learned something extremely useful about the sink.

Example: Attribute Context

Maybe your input appears here:

<input value="USER_INPUT">

Now you are inside an HTML attribute.

The interesting question becomes:

Can I escape from this attribute?

Characters such as:

"
'
>
<

become important because they can potentially affect the HTML structure.

If the server safely converts:

"

into:

&quot;

your attempt to escape the attribute might fail.

This is why blindly pasting:

<scrip>alert(1)</scrip>

into every field isn't particularly good XSS testing.

Sometimes <scrip> isn't even relevant to the context you're dealing with.

Example: JavaScript Context

Now imagine the server produces:

const username = "USER_INPUT";

We're not really dealing with normal HTML anymore.

We're inside a JavaScript string.

Now things such as:

quotes
escaping
backslashes
semicolons
template literals

become much more relevant.

The browser isn't trying to identify if this valid HTML, instead of that is validating if this is valid JavaScript

That change in context completely changes how you analyze the vulnerability.

Why alert(1) Exists Everywhere

Let's clear something up.

This:

alert(1)

is not the attack.

It is usually just a proof of concept.

You could also use:

alert(document.domain)

or modify something harmless on the page.

The point is simply to demonstrate:

I control JavaScript execution.

Once that happens, the security question changes from:

Can JavaScript execute? to What can JavaScript do inside this application?

That's where impact analysis begins.

What Can XSS Actually Do?

The exact impact varies a lot.

A tiny reflected XSS on a public page might not be particularly impressive.

A stored XSS that executes inside an administrator's dashboard can be critical.

Potential consequences include:

Performing actions as the victim
Reading sensitive information displayed in the page
Modifying application content
Changing account settings
Capturing information entered into the application
Interacting with internal application APIs
Targeting privileged users
Creating convincing phishing interfaces inside the trusted site
Chaining with other vulnerabilities

PortSwigger notes that attacker-controlled JavaScript may be able to perform actions available to the victim, read information the victim can access, and modify data available to them.

But What About Stealing Cookies?

You'll hear this constantly when learning XSS:

document.cookie

And yes, historically, stealing session cookies was one of the classic demonstrations of XSS.

But modern applications frequently protect important session cookies with:

HttpOnly

which prevents JavaScript from directly reading them.

So:

document.cookie

may not contain the authentication token you're hoping for.

Does that make XSS useless?

Not at all.

This is an important misconception.

If JavaScript is running inside an authenticated user's browser, it may not need to know the session token.

The browser already has it.

Conceptually:

Victim logs in
      ↓
Browser receives session
      ↓
XSS executes
      ↓
Injected JavaScript interacts with application
      ↓
Browser automatically uses the victim's session

So modern XSS exploitation is often more interesting than simply:

steal cookie → hijack account

The attacker may instead attempt to use the victim's existing session to interact with the application.

Admin XSS Is Where Things Get Interesting

Suppose your XSS only appears on your own profile.

Not very exciting.

Now suppose that same profile is reviewed by an administrator.

Different story.

Imagine:

Attacker
   ↓
Changes profile field
   ↓
Stored in database
   ↓
Administrator opens user profile
   ↓
Payload executes as administrator

This can turn a vulnerability accessible to a normal user into something much more serious.

When pentesting, I would pay extra attention to fields eventually displayed in:

Admin panels
Moderation systems
Support dashboards
CRM platforms
Monitoring dashboards
Logs
Analytics interfaces
Back-office applications

Blind XSS

This leads us to Blind XSS.

Blind XSS is basically stored XSS where you cannot directly see the place where your payload eventually executes.

Imagine a contact form:

Name:
Email:
Message:

You submit data.

The public website simply responds:

Thanks for contacting us.

Nothing happens.

But behind the scenes:

Your input
    ↓
Database
    ↓
Internal customer support dashboard
    ↓
Employee opens the message

If that internal dashboard renders the input unsafely, your payload might execute there.

From your perspective, the execution happened somewhere you could not see.

That's why it's called blind XSS.

And those situations can be particularly interesting because the person triggering your payload may have much higher privileges than you.

Self-XSS

You may also hear the term Self-XSS.

This is when the only person you can make execute the payload is yourself.

For example, imagine you must:

  1. Open your browser console.
  2. Paste malicious JavaScript.
  3. Press Enter.

Well…

You already control your own browser.

So by itself that isn't really a meaningful security issue.

Self-XSS becomes interesting only when there is some realistic way to convince another user to perform the required action, usually through social engineering or by chaining the behavior with another weakness.

PortSwigger similarly distinguishes self-XSS from normal reflected XSS because the victim normally needs to manually submit the payload themselves.

Is XSS Still Relevant Today?

Absolutely.

But the answer deserves some nuance.

XSS is old.

Browsers are better.

Frameworks are better.

Developers have better libraries.

Security headers exist.

Modern frameworks such as React, Angular, and Vue often escape output automatically in common situations.

Cookies can be protected with HttpOnly.

Content Security Policy can significantly restrict JavaScript execution.

So yes, exploiting XSS in modern applications can sometimes be harder than it was fifteen years ago.

But XSS did not disappear.

As of the OWASP Top 10:2025, XSS remains part of the A05: Injection category. OWASP describes XSS as a high-frequency issue and reports more than 30,000 CVEs associated with it in the dataset used for the ranking.

Even more interestingly, MITRE ranked CWE-79 — Cross-Site Scripting — as the #1 weakness in the 2025 CWE Top 25 Most Dangerous Software Weaknesses. MITRE's dataset also associated seven CWE-79 vulnerabilities with CISA's Known Exploited Vulnerabilities catalog.

That gives us a pretty clear answer:

Is XSS old?
Yes.
Is XSS solved?
No.

Is XSS Actually Exploited in the Real World?

Yes.

CISA's Known Exploited Vulnerabilities catalog exists specifically to track vulnerabilities with evidence of exploitation in the wild, and XSS-related vulnerabilities have appeared there.

For example, CISA listed CVE-2024–44309, affecting multiple Apple products, as a known exploited vulnerability involving malicious web content that could lead to XSS.

That doesn't mean every reflected XSS you find is going to be exploited by sophisticated attackers.

Far from it.

XSS severity depends heavily on:

Where the vulnerability exists
Who can trigger it
Who receives the payload
What privileges the victim has
Whether authentication is required
Which browser protections exist
Which CSP policies exist
What the JavaScript can access
Whether the vulnerability can be chained

That's why you'll sometimes see an XSS rated relatively low and another rated high or critical.

Same vulnerability family.

Very different attack scenario.

Why Do We Still Find XSS?

Because modern web applications are incredibly complicated.

Think about what happens in a typical frontend today:

API responses
      ↓
JavaScript
      ↓
JSON
      ↓
Framework components
      ↓
DOM manipulation
      ↓
Third-party libraries
      ↓
User-generated content

Now add:

Legacy JavaScript
Markdown renderers
Rich-text editors
SVG
File previews
Template engines
Analytics data
postMessage()
WebSockets
Client-side routing
Server-side rendering

There are plenty of opportunities for untrusted data to accidentally reach a dangerous context.

The attack surface changed.

XSS didn't disappear with it.

Modern Frontend Frameworks Help, But They're Not Magic

For example, React normally escapes values rendered like this:

<div>{username}</div>

That makes straightforward HTML injection much harder.

Good.

But applications eventually need features such as:

Rich HTML rendering
Markdown
WYSIWYG editors
Embedded content
Dynamic templates
Legacy components
Third-party widgets

Then developers start deliberately bypassing those safety mechanisms.

For example, React has:

dangerouslySetInnerHTML

And the name isn't exactly subtle.

Whenever an application intentionally turns strings back into HTML, the possibility of XSS becomes relevant again.

The same principle applies regardless of framework:

SAFE DATA
     ↓
someone decides it should become HTML
     ↓
dangerous parsing boundary appears

Example 1 — Reflected XSS

Imagine:

GET /search?q=hacking

The application returns:

<h2>Results for: hacking</h2>

First, I might try something harmless:

<b>XSS_TEST</b>

If I receive:

<h2>Results for: <b>XSS_TEST</b></h2>

and it renders as bold text, I've learned that HTML is being interpreted.

Next, in an authorized test environment, a simple execution proof might be:

<scrip>lert(1)</scrip>

If the browser executes it:

User input
    ↓
Server response
    ↓
HTML parser
    ↓
JavaScript execution

We have reflected XSS.

Example 2 — Event Handler XSS

Sometimes <scrip>ags are filtered.

That doesn't necessarily mean XSS is impossible.

JavaScript can also execute through HTML event handlers.

For example:

<img src=x onerror=alert(1)>

Here the logic is:

Browser creates <img>
        ↓
Attempts to load "x"
        ↓
Loading fails
        ↓
onerror event fires
        ↓
JavaScript executes

This is a good example of why:

Block <scrip>

is not a real XSS defense.

The browser provides many ways for HTML and JavaScript to interact.

Example 3 — Stored XSS

Imagine a vulnerable blog comment:

<div class="comment">
USER_COMMENT
</div>

Submit:

<b>HELLO</b>

Reload the page.

If you see bold text, HTML injection has been confirmed.

Now imagine a harmless proof of JavaScript execution is stored instead.

The important difference is persistence:

Attacker submits payload
        ↓
Application stores payload
        ↓
Attacker leaves
        ↓
Victim visits later
        ↓
Browser loads stored content
        ↓
Payload executes

That is why stored XSS can have a much larger blast radius.

Example 4 — DOM XSS

Consider:

const name = location.hash.substring(1);
document.getElementById("welcome").innerHTML = name;

Visit:

https://example.com/#David

The browser effectively creates:

<div id="welcome">
David
</div>

But the important part is:

location.hash
       ↓
name
       ↓
innerHTML

We have:

Source → Sink

The server might never even see the fragment.

Everything happens inside the victim's browser.

That is classic DOM XSS territory.

Example 5 — Safe vs Unsafe DOM Manipulation

Compare these two lines:

element.innerHTML = userInput;

and:

element.textContent = userInput;

They look similar.

Security-wise, they're very different.

With:

innerHTML

the browser is essentially told:

Parse this as HTML.

With:

textContent

the browser is told:

Display this as text.

So if:

userInput = "<b>Hello</b>";

then:

innerHTML

produces:

Hello

while:

textContent

produces:

<b>Hello</b>

That distinction captures the entire XSS problem surprisingly well.

A Better Way to Hunt for XSS

Instead of randomly throwing payloads everywhere, think like this:

1. Find input you control.
2. Find where that input appears.
3. Identify the context.
4. Check what characters survive.
5. Determine how the browser parses the result.
6. Look for a path to JavaScript execution.
7. Evaluate what that execution actually gives you.

Or even shorter:

INPUT
  ↓
CONTEXT
  ↓
PARSING
  ↓
EXECUTION
  ↓
IMPACT

That's the workflow worth remembering.

Not:

Paste <scrip>alert(1)</scrip> everywhere and hope.

Final Thoughts

XSS is one of those vulnerabilities that looks almost trivial when you first learn it.

You inject:

<scrip>alert(1)</scrip>

A popup appears.

Done.

But once you understand what's happening underneath, it becomes much more interesting.

The real issue is a broken trust boundary:

Attacker-controlled data
         ↓
Trusted application
         ↓
Victim's browser
         ↓
Attacker-controlled code

The application allowed data to become code.

And once attacker-controlled JavaScript runs inside a trusted origin, the real question is no longer whether you can make an alert appear.

The real question becomes:

What can I do with the privileges of the user who executes it?

That's where XSS goes from a simple browser trick to a real security vulnerability.

And despite decades of research, modern frameworks, browser protections, CSP, sanitization libraries, and secure coding guidance, it continues to appear in real applications.

So if you're studying web pentesting, don't learn XSS as a collection of payloads.

Learn the browser.

Learn HTML parsing.

Learn JavaScript contexts.

Learn sources and sinks.

Learn how user-controlled data travels through an application.

Once you understand that, XSS stops looking like magic.

It becomes a data-flow problem.

And those are much easier to hunt.