Intro to Cross-Site Scripting (XSS)

Cross-site scripting (XSS) happens when attacker-controlled content is treated as executable code in another user's browser, within a trusted site's origin.

Common XSS types

All three involve the same underlying mistake: untrusted input reaches an executable browser context without the correct encoding or sanitisation.

How it happens

A page takes user input and puts it into the HTML without encoding it as text. If that input contains markup the browser treats as code, the browser will run it.

For reflected and stored XSS, the main difference is how the input reaches the page and who has to do what for it to run.

Reflected

The payload lives in the request — usually a query parameter or a form field. The server copies it into that response and stops there. Nothing is saved.

A search page that prints "You searched for: [your input]" is the usual shape:

<p>You searched for: <?php echo $_GET['q']; ?></p>

app.get("/search", (request, response) => {
  response.send(`<p>You searched for: ${request.query.q}</p>`);
});

@app.get("/search")
def search():
    return f"<p>You searched for: {request.args.get('q', '')}</p>"

All three examples are intentionally vulnerable because they place the value directly into HTML.

?q=<script>alert(1)</script> comes back as:

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

You see the alert in your own browser. For the same script to run as someone else, they have to open that URL (or submit that form):

Stored

The payload is written down — a comment, a profile field, a ticket — and the server serves it later as part of a normal page. You plant it once. Everyone who loads that page runs it, including staff who open the queue.

Same injection, different delivery. You do not need to send each victim a link. You need a place the app will store your input and show it again.

DOM-based

DOM-based XSS happens in browser-side JavaScript. The page reads attacker-controlled data and writes it to an unsafe sink without first making it safe for that context:

const name = location.hash.slice(1);
document.querySelector("#welcome").innerHTML = name;

The URL fragment is not sent to the server. The browser reads it, and innerHTML parses it as markup. If the page used textContent instead, the same value would be displayed as text.

Start with context

1. Where does my input land in the response?
2. Is that spot plain text, HTML, an attribute value, or JavaScript?
3. What is the smallest payload that runs in that exact spot?

An attribute is a name="value" pair on a tag. In <input value="hello">, value is the attribute and hello is its value.

A sink is the exact place where the application writes the input, such as HTML text, an attribute, or innerHTML.

Context quick reference

The same payload does not work in every row because each parser gives different characters special meaning.

If the page puts your search into the body:

<p>You searched for: [your input]</p>

<script>alert(1)</script> becomes a real <script> tag. The browser runs it.

If the same input is put inside an attribute:

<input value="[your input]">

then ?q=<script>alert(1)</script> becomes:

<input value="<script>alert(1)</script>">

That is still one input. The <script> is text in the value string. It does not run.

Close the attribute and the tag first, then start a script:

"><script>alert(1)</script>

<input value=""><script>alert(1)</script>">

The " ends value, > ends the input, and the <script> is now its own tag.

If the attribute uses single quotes (value='[your input]'), close with '>.

Encoding versus filtering

These two responses look similar but mean different things:

• If <script> becomes <script>, the value has been HTML-encoded. The browser displays it as text instead of parsing it as a tag.
• If only the script tag is deleted while other HTML remains active, the page is using a naive blocklist. Other tags and event attributes may still execute JavaScript.

The examples below apply to the second case: the specific tag is removed, but the input still lands in active HTML.

Body context, script removed:

<p>You searched for: [your input]</p>

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

becomes:

<p>You searched for: <img src=x onerror=alert(1)></p>

src=x is a bad image URL. onerror runs when that load fails. The browser still runs alert(1). <svg onload=alert(1)> is the same idea: a tag the filter did not strip, with an event that runs immediately.

The exact payload depends on where the input lands. Identify the context first; do not keep adding bypasses to a payload designed for a different context.

After the alert

alert(1) means JavaScript ran in the page that reflected it. The browser treats that script as the site's own code — same origin as https://shop.example, not as a file you opened from disk.

Same origin means the script can do what the site's own pages can do for that user:

If document.cookie is empty, there may be no script-readable cookies, or the session cookie may be HttpOnly. That does not stop same-origin requests: fetch to a same-site URL still uses the browser's normal cookie rules.

That matters when someone else will open your URL.

Look at the rest of the app once the script runs: extra forms, a "send to reviewer" box, JSON endpoints. Those are often the real goal. In a CTF, the flag is whichever of those the author left reachable.

How to prevent it

Server-rendered HTML

Flask configures Jinja to auto-escape values in HTML templates. Pass the search value to the template, then print it normally:

return render_template("search.html", query=request.args.get("q", ""))

<p>You searched for: {{ query }}</p>

If query contains <script>, Jinja encodes the angle brackets and the browser displays the value as text. Do not apply Jinja's safe filter to untrusted input; that disables the protection.

React

React also escapes text rendered normally in JSX:

function SearchResult({ query }) {
  return <p>You searched for: {query}</p>;
}

dangerouslySetInnerHTML bypasses that normal protection and writes a raw HTML string:

function SearchResult({ query }) {
  return <p dangerouslySetInnerHTML={{ __html: query }} />;
}

The second version is unsafe when query contains user input. Only use dangerouslySetInnerHTML with trusted or properly sanitised HTML.

Browser-side text

When a value should be displayed as text, use textContent instead of innerHTML:

const output = document.querySelector("#search-result");
output.textContent = new URLSearchParams(location.search).get("q") ?? "";

The browser creates a text node instead of parsing the value as HTML.

Defence checklist

• Use framework templates with automatic, context-aware output encoding.
• Put plain text into safe DOM APIs such as textContent.
• If users are allowed to submit some HTML, sanitise it with a maintained allow-list-based tool such as DOMPurify.
• Validate input for the application's rules, but do not treat input filtering as a replacement for output encoding.
• Use a restrictive Content Security Policy as defence in depth, not as the primary fix.

Deleting the word script is not a fix. The event-handler examples above show why a blocklist misses other executable HTML.

A simple workflow

1. Locate the reflected input.
2. Identify the context.
3. Prove execution with one small payload.
4. Ask what that script can reach in this origin, especially if another user can be sent the page.

Common mistakes

• Pasting the same payload into every field without identifying the output context.
• Treating a reflected string as XSS before proving that JavaScript executes.
• Assuming that deleting <script> prevents event-handler or other context-specific payloads.
• Stopping at document.cookie even though same-origin application features may still be reachable.

Tools and resources

• PortSwigger's XSS guide for reflected, stored, DOM, and context-specific examples
• OWASP Cross Site Scripting Prevention Cheat Sheet for output encoding, safe sinks, sanitisation, and CSP guidance

Only practise against systems you own or are explicitly authorised to test, such as this lab.

Self-check

alert(1) works. document.cookie is empty. Are you done?

No. You already have JavaScript on this origin. See what else the page offers, and whether anyone else can be sent the URL.

Next

The X-Scripts