Beyond the basics: how do advanced XSS vulnerabilities work?

Advanced cross site scripting goes beyond a script tag in a search box. It exploits context, such as an HTML attribute or a script block, client side code that writes untrusted data into the page, and gaps in sanitisers. The reliable defence is correct output encoding for each context, backed by safe APIs and a content security policy.

What is XSS, precisely?

MITRE's CWE-79 names the weakness Improper Neutralization of Input During Web Page Generation. In plain terms, the application puts data into a page without making it inert, so a browser may treat it as code. OWASP puts it simply: for an attack to succeed the attacker must be able to insert and execute malicious content in a page, so all variables should be treated as untrusted and handled with the right controls.

Why does context matter?

The same string is dangerous in some places and harmless in others. The OWASP cheat sheet separates output encoding for HTML contexts, HTML attribute contexts, JavaScript contexts, CSS contexts and URL contexts. Encoding that is right for the body of a page can be wrong inside an attribute value or inside a script block.

Common mistakes follow from that. Encoding once at input and storing the result, then using the data in another context later. Using an HTML encoder for a value that lands in a URL. Placing untrusted data directly inside a script block, a spot the cheat sheet treats as dangerous unless it is handled in a very specific way.

What is DOM based XSS?

In DOM based XSS, the flaw is in the browser side code. The server may send a clean page, but a script reads from somewhere an attacker can influence, such as the URL fragment or a message from another window, and writes it into the page with an unsafe method. Server side encoding never sees it. OWASP keeps a separate cheat sheet for this class because the sinks and fixes differ: prefer safe sinks that treat data as text, and avoid methods that parse strings as HTML.

Where do sanitisers and policies fall short?

Sometimes you must allow some HTML, for example in a rich text field. A sanitiser removes dangerous parts. OWASP's guidance is to use a maintained library and keep it updated, because the problem is hard and parsing differences between a sanitiser and a browser have caused bypasses.

A content security policy limits where scripts may load from and run, which can blunt an injection. The OWASP cheat sheet lists sole reliance on CSP among its ineffective approaches, noting that browser support differs and legacy applications can make strict policies hard. Treat CSP as a second layer, not as the fix.

A constructed example

A single page application reads a "welcome" value from the URL fragment and assigns it into the page as markup. Server logs never show the value, because fragments are not sent to the server, and the server's output encoding is irrelevant. A reviewer using a code scanner finds the assignment.

The fix is to set the text content instead of markup, so the browser treats it as characters. The team then adds a strict content security policy, which would limit the damage if a similar flaw reappears, and a test that fails the build when the unsafe method is used with external data.

How to check or apply this

1. Inventory every place untrusted data enters a page: parameters, stored fields, headers, URL fragments, messages and third party data.
2. Use a template engine or framework that encodes output by context by default, and ban the escape hatches in code review.
3. For each place where data is written to a page in browser code, use text assigning methods, not markup methods.
4. Where HTML must be allowed, use a maintained sanitiser, pin and update it, and add tests with known tricky inputs.
5. Add a content security policy and run it in report only mode first.
6. Add static analysis rules and tests that fail on unsafe sinks.
7. Test manually with a checklist of contexts, not just a single payload.

Quick check

Sources

• MITRE CWE-79, Cross-site Scripting
• OWASP Cross Site Scripting Prevention Cheat Sheet
• W3C Content Security Policy Level 3

Last reviewed: 18 October 2026.