Cross-site scripting (XSS): examples, fixes and a test checklist

Cross-site scripting (XSS) is a flaw where a web application puts untrusted data into a page without the encoding that spot needs. The browser then treats that data as code and runs it with the privileges of your site. CWE-79 names the weakness "Improper Neutralization of Input During Web Page Generation". OWASP's Top 10:2025 files XSS under A05 Injection.

This page covers the three types, a worked example, the encoding rule for each output context, fixes for several stacks, defense layers, and how testers prove a finding. Test only systems you own or have written authorization to test.

What is cross-site scripting?#

XSS lets a script that you did not write run inside your page. The script runs in your origin, so the browser gives it the same access as your own code. It can read what the page shows, call your APIs with the user's session and change the page.

The root cause is simple. An application builds HTML, JavaScript or a URL by joining strings, and one of the strings came from a user. OWASP's cheat sheet says coverage is what matters: an application that protects 99 places and misses one is still vulnerable.

How does an XSS attack work?#

The attacker gets a value into a page that another person views, and the page prints it without encoding. The example below uses a fictional app.

app.get('/search', (req, res) => {
  res.send('<h1>Results for ' + req.query.q + '</h1>');
});

GET /search?q=<img src=x onerror=alert(document.domain)> HTTP/1.1
Host: notes.example.com

<h1>Results for <img src=x onerror=alert(document.domain)></h1>

The fix is to treat the query as text. A template engine that escapes by default turns < into <, and the browser then prints the characters instead of running them.

What are the three types of XSS?#

XSS has three types, and they differ in where the untrusted data travels before it runs. PortSwigger uses the same three groups.

OWASP defines stored attacks as those where the injected script is permanently stored on the target server, for example in a database, forum, visitor log or comment field. Stored XSS usually has the highest impact because it needs no crafted link. Read the full guide: stored XSS. In DOM-based XSS the server response may be clean, and the flaw sits in the page's own JavaScript. Read the full guide: DOM-based XSS.

What can an attacker do with XSS?#

Injected script acts as the logged-in user inside your site. The usual outcomes are these:

• Perform actions as the user, such as changing an email address or posting content.
• Read data the page can read, including CSRF tokens, personal data and API responses.
• Change what the user sees, for example by adding a fake login form.
• Take a session token that scripts can read (cookies without HttpOnly, tokens in localStorage).

The impact scales with the viewer. Script that runs in an administrator's session reaches administrator functions. Testers rate that case higher than the same flaw seen only by the author.

Which output encoding fits which context?#

Use the encoder that matches the place where the data lands. HTML encoding does not protect a JavaScript string, and JavaScript encoding does not protect a URL. OWASP's cheat sheet makes this point and warns that a servlet filter cannot know the output context.

How do you fix XSS in each stack?#

Start with the framework's default escaping and avoid the escape hatches. The table shows each default and the call that turns it off.

React's docs say that untrusted HTML passed to dangerouslySetInnerHTML risks an XSS vulnerability. Angular's docs say Angular treats all values as untrusted by default. Django escapes template variables automatically, and Go's html/template escapes by context. Check the Vue and Razor rows in each project's own docs before you rely on them.

Express with EJS (use <%= %>, not <%- %>):

// views/search.ejs
// <h1>Results for <%= q %></h1>   escaped
// <h1>Results for <%- q %></h1>   raw: do not use for user data
app.get('/search', (req, res) => res.render('search', { q: req.query.q }));

Python with Flask and Jinja2. Autoescape is on for .html templates, so print the variable with the normal double-curly output tag. Avoid the safe filter and Markup() on user data. When you build a string in Python, escape it yourself:

from markupsafe import escape

@app.get("/search")
def search():
    q = request.args.get("q", "")
    return "<h1>Results for " + str(escape(q)) + "</h1>"

PHP without a template engine (htmlspecialchars):

<h1>Results for <?= htmlspecialchars($_GET['q'] ?? '', ENT_QUOTES, 'UTF-8') ?></h1>

Java with Spring and Thymeleaf (th:text escapes, th:utext does not):

<h1>Results for <span th:text="${q}"></span></h1>

For client-side code, write text with textContent and not innerHTML. The page on DOM-based XSS covers sinks in detail.

Which defense layers help when a bug slips through?#

Encoding is the fix. These layers reduce the damage when a flaw remains, and none of them replaces it.

MDN documents the cookie attributes, and its CSP guide documents the policy directives. A starting policy for a site with no inline scripts:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'

What real XSS incidents and CVEs exist?#

Real cases show how a small gap grows. Each row links to its source.

How do penetration testers find and prove XSS?#

Testers prove XSS with script that runs in a real browser, in the victim origin, with evidence. A reflected string alone is not a finding. Our method for web application penetration testing follows these steps:

1. Find each place where input is reflected, stored or read by client script. Include URL parts, headers, JSON fields, file names and API responses that a front end renders.
2. Send a unique, harmless marker and find where it appears in the response and in the rendered DOM.
3. Record the output context for each hit: HTML body, attribute, JavaScript, URL or CSS.
4. Send a minimal context-specific proof, such as alert(document.domain) or print(), and watch it in a real browser.
5. Run controls: the same request with the marker only, a second account, and a signed-out session. A control shows whether the effect depends on the payload and not on an error page.
6. For stored cases, load the page from a second session to show the data was stored in one request and ran in another.
7. Record the request, the response excerpt, the browser name and version, the context and the cookie flags.

A finding counts only when the script runs in the victim origin. The report labels it "Browser-observed" and lists what was not tested. The same method covers APIs that return HTML fragments. See API penetration testing.

Controls that held go in the report too. If the app encoded the marker in the HTML body but not in an attribute, the report says so, so the fix does not break the encoding that works.

Cross-site scripting testing checklist#

Use this list in a test plan. Each item maps to a finding or to a control that held.

1. List every input: query, path, body, headers, cookies, file names, WebSocket messages, imported data.
2. Search every view that renders that input, including admin pages, emails, exports and logs.
3. Check the output context for each hit and compare it to the encoding table above.
4. Check client code for sinks (innerHTML, document.write, eval, href assignment).
5. Check each framework escape hatch in the source: dangerouslySetInnerHTML, v-html, |safe, Html.Raw.
6. Check user HTML paths: which sanitizer, which version, which configuration.
7. Read the CSP: does it allow unsafe-inline, wildcard hosts or data URLs for scripts?
8. Check cookie flags and where tokens live (cookie or localStorage).
9. Check that responses declare the right Content-Type and X-Content-Type-Options: nosniff.
10. Retest after the fix with the same request in a browser, and keep the controls.

XSS vs CSRF: what is the difference?#

XSS runs attacker script inside your site. CSRF makes the user's browser send a request that the user did not intend. WSTG-SESS-05 describes CSRF as forcing an end user to execute unintended actions in an application where they are authenticated.

Fix both. A site with an XSS flaw cannot rely on CSRF tokens.

When should you get a professional XSS test?#

Get a professional test when your app renders user content, has several roles, or loads a lot of client-side JavaScript. Scanners find simple reflected cases. Judging context, roles and second-order storage takes a person who reads the browser result. Excession Labs tests XSS as part of web application penetration testing and API penetration testing, with written authorization, browser-observed evidence and fix guidance for each finding. Request a web application test from the service page.