Why XSS Persists in This Frameworks Era?

Of course, if you restrict the tags and attributes much, much more, it’s theoretically possible to achieve safety. But at that point, I feel it’s worth reconsidering whether your implementation accepting HTML is truly necessary in the first place.

A-3. Misuse of Open-Source Sanitizers

So, when sanitization is necessary, you should use a widely used and trusted open-source library. For example, OWASP recommends DOMPurify¹⁶.

OWASP recommends DOMPurify for HTML Sanitization.

However, even the best sanitizers are ineffective if used incorrectly.

A common pattern known as “desanitization” means modifying or using wrongly the output of a sanitizer and introducing vulnerabilities as a result¹⁷. OWASP also warns about this risk¹⁸.

If you sanitize content and then modify it afterwards, you can easily void your security efforts. If you sanitize content and then send it to a library for use, check that it doesn’t mutate that string somehow. Otherwise, again, your security efforts are void.

You can see a well summarized examples on a Sonar’s report¹⁹. Let’s pick up some and the first is as below.

// (1) sanitize  
data = DOMPurify.sanitize(userInput);  
// (2) modify  
data = data.replace(/class=".*?"/, 'class="custom-class" ');  
// (3) use  
document.body.innerHTML = data;  

So, where is the vulnerability? The HTML should be safe after passing through DOMPurify.

However, as Sonar states in their article, the very belief that sanitized data is permanently safe for any subsequent modification or use is a dangerous misconception. As proof, this code can lead to XSS if userInput is class=" <div id="<img src onerror=alert(1)>">.

userInput = 'class=" <div id="<img src onerror=alert(1)>">';  
// (1) sanitize  
data = DOMPurify.sanitize(userInput);  
// class=" <div id="<img src onerror=alert(1)>"></div>  
// (2) modify  
data = data.replace(/class=".*?"/, 'class="custom-class" ');  
// class="custom-class"<img src onerror=alert(1)>"></div>  
// (3) use  
document.body.innerHTML = data; // triggers alert(1)  

Furthermore, even if you don’t modify the data directly, some of you might be using sanitized HTML by embedding it within other HTML. This can also lead to XSS in some cases²⁰.

B. Cases Where Framework Escaping Mechanisms Are Not Used Even Though Can Be Used

In the first half, we looked at cases where “the framework’s escaping mechanism is unavailable”.

Well, are we safe in situations where the escaping mechanism can be used? Unfortunately, that’s not always the case. For example, there are instances where a framework’s protective features are limited, or where developers use them incorrectly.

As a prerequisite, remember that XSS sinks are diverse. In reality, each type of sink requires a different kind of escaping²¹. For instance, a URL requires URL-specific escaping, while an HTML attribute needs a different kind of escaping. It’s fine if you’re using a framework like React that automatically applies the correct processing in the right place, but when the developer has to select and apply the appropriate escaping method, it’s not a simple task.

Furthermore, if the escaping mechanism is built into the framework’s syntax like in React (where you just need to put it in {}), there’s little risk of forgetting. Otherwise, mistakes can happen. For example, jQuery requires using the text() method to treat HTML as text, but a report on HackerOne #243363 appears to show a case where this call was forgotten, or a different, incorrect escaping method was chosen.

// note by author: XSS can be achieved by `msg`.
$(document).ready(function () {
  const msg = window.location.search.match(/[&?]msg=([^&]+)/);
  const msgText = msg ? decodeURIComponent(msg[1]) : "No data collected for this metric, cannot generate analytics.";

  $(document.body).html(Utils.infoMessage(msgText));
});

Moreover, even when a framework’s features are easy to use, escape might be intentionally omitted due to implementation effort or time constraints, or approved with a “this should be fine” attitude. For instance, consider a case where complex JSON must be processed before it can be properly fitted into JSX, and a developer skips that tedious processing. The rendering of complex dynamic forms is a typical example of these cases.

Underlying such omissions and approvals is the judgment that “this input is probably safe”. But, as mentioned earlier with the Google paper, this judgment is, unfortunately, very often wrong. While I cannot disclose details, such cases have actually been discovered during our company’s security assessments.

To summarize, there are mistakes and decisions that lead to framework defense mechanisms being used improperly or not at all. This is a problem that can occur in various situations, such as during a transition to new technology when developers are unfamiliar with a framework, during the early and rushed stages of development, or in development situations constrained by a lack of time.

Sinks That Exist Outside of a Framework’s Protection Scope

Next, let’s discuss sinks that are often not protected by framework. They are less likely to be recognized as XSS risks, although these sinks appear in common development scenarios.

HTML Attribute (URL)

This is the case of using untrusted data as a URL in an HTML attribute value. For example, <a href="${userInput}">Link</a> is a straightforward case where if a URL with javascript: is put into userInput, a script will be triggered when the <a> tag is clicked.

Implementations like this are prone to appear in the following situations.

• When you’d like to set the href of <a> or src of <img> based on a value received via postMessage or other communication mechanisms. An example is to use an image selected within a popup window in the original tab. The following is vulnerable code actually reported in HackerOne report #1379400 .

Meteor.startup(function() {
    MessageTypes.registerType({
        id: 'message_snippeted',
        system: true,
        message: 'Snippeted_a_message',
        data(message) {
            const snippetLink = `<a href="/snippet/${ message.snippetId }/${ encodeURIComponent(message.snippetName) }">${ escapeHTML(message.snippetName) }</a>`;
            return { snippetLink };
        },
    });
});

• Though it may be rare, standard spec sometimes says that a URL must be set as an attribute value. HackerOne report #2515808 is really interesting, because the vulnerability arose while implementing a flow defined by the “OAuth2 form post response mode” specification, which involves setting a URL in action attribute of <form>. It’s more of an HTML injection than XSS, though.

JavaScript (URL)

This involves using an untrusted URL with JavaScript APIs like window.open() or location.href. If a javascript: scheme URL is passed, a script is executed.

This pattern is frequently found in the two.

• redirect like #2611305

• opening popup windows like #728001

Especially, automatic redirection after login is dangerous because it’s typically done with an authorized session.

JavaScript (Function Construction)

This is the case of dynamically constructing and executing a script from untrusted data. For example, eval(userInput);.

You might be thinking, “Does that pattern even exist these days?”, but real-world examples do exist. HackerOne report #2670521 is a case where XSS was triggered when the value '};alert('XSS');var x={y:' was submitted through a form. Although the details haven’t been disclosed, it’s likely that the application was generating and executing a script from a search query string entered by the user.

Supplement: Frameworks That Do Validate URLs

I hope you now see that these sinks, which frameworks tend to overlook, often appear when implementing “common” features. This can be considered another reason why XSS continues to be a problem today, even with the widespread use of frameworks.

However, to say that frameworks completely ignore these sinks would also be incorrect. For example, the isUrl function, a standard validator used in frameworks like Laravel, rejects javascript: scheme²². Additionally, React v19 has finally handled javascript: scheme in the href attribute²³ and XSS via <object>²⁴.

Nevertheless, protection for these sinks is often weaker compared to the HTML-related sinks mentioned earlier. I feel that caution is still required.

XSS Caused by Library Misuse

Another point that’s often overlooked is XSS arising from the incorrect use of libraries. This isn’t about vulnerabilities in the libraries themselves that Dependabot would alert you to. Rather, it’s the perspective that XSS can be created by not correctly understanding a library’s specifications and misusing it.

For example, there’s a common pattern where a value set as the content property in a tooltip library is interpreted as HTML. The HTML output by markdown libraries also requires caution.

However, on this point, recent libraries have incorporated measures to prevent such misuse. For instance, the tooltip library “Tippy.js” controls this with an allowHTML option²⁵, and the markdown parser “marked” includes a very prominent warning in its README²⁶.

Still, I feel it wouldn’t be surprising to find libraries with dangerous interfaces that are exposed without much fanfare, and I believe it’s best to be careful with patterns that have low visibility, such as the difference between <%= (with HTML escaping) and <%- (without HTML escaping) in EJS syntax.

The Effectiveness of Multi-Layered Defense for XSS

Now, up to this point, we’ve looked at very specific, individual causes of XSS. Here, allow me to discuss something with a slightly different flavor: the effectiveness of multi-layered XSS defenses like CSP and WAFs.

To state the conclusion first, while it’s great to utilize these as additional security layers, it’s dangerous to think “we have CSP and WAF, so we’re safe for now” without taking a fundamental approach to the root causes we’ve discussed so far.

First, let’s look at CSP (Content Security Policy). As you may know, it’s said to be quite difficult to configure correctly. It’s so difficult that the CSP Level 3 specification itself states, “Deployment of an effective CSP against XSS is a challenge”²⁷. In fact, numerous bypasses for host-based CSP policies have been discovered, including research about “script gadgets”²⁸. For example, in the HackerOne report #2279346 , because scripts from https://www.google.com/recaptcha/ were permitted by the CSP, a CSP bypass was successfully executed by utilizing an Angular mechanism included in reCAPTCHA. Additionally, in #2246576 , although the details are unknown, a CSP bypass was performed on GitHub Enterprise Server.

In response to this, Strict CSP was proposed. In short, it’s a configuration method that says, “it’s sure that CSP tends to get bypassed, but if you set it up this way, it should be fine!”. It is defined in the CSP Level 3 specification , and web.dev also provides guidance on how to implement it . The idea behind Strict CSP is to control scripts using dynamic random values or hash values instead of hosts. This configuration can certainly reduce XSS risk significantly. On the other hand, there is the problem of high implementation costs. In fact, according to the 2024 Web Almanac published by the HTTP Archive, 91% of desktop sites and 92% of mobile sites using CSP still include unsafe-inline in their script-src directive²⁹.

Considering these implementation difficulties and the actual situation, it doesn’t seem achievable to prevent XSS with CSP alone.

So, what about Trusted Types? This is a mechanism that forces input values for APIs that can become XSS sinks to have passed a validation defined by the page’s developer. The primary disadvantage is that it can only be used in Chromium-based browsers, meaning Firefox and Safari do not support it. Additionally, bypasses for this are also being researched. The repository “Cursed Types” collects XSS sinks that can slip through Trusted Types. The following pattern is an easy-to-understand example from the repo. XSS sinks are so diverse, aren’t they?

let attackerControlledString = '<img src=x onerror=alert(origin)>';
const blob = new Blob([attackerControlledString], {type: 'text/html'});
const url = URL.createObjectURL(blob);
location.href = url;

What about WAF? Yes, the situation is the same. There are many bypasses. It’s gotten to the point where even OWASP is sounding the alarm³⁰.

WAF’s are unreliable and new bypass techniques are being discovered regularly. WAFs also don’t address the root cause of an XSS vulnerability. In addition, WAFs also miss a class of XSS vulnerabilities that operate exclusively client-side. WAFs are not recommended for preventing XSS, especially DOM-Based XSS.

So far, we’ve looked at CSP, Trusted Types, and WAF. It seems none of them can prevent XSS on their own.

The important thing to understand is that all multi-layered defense measures for XSS only serve to reduce the risk of XSS. In other words, they don’t fundamentally eliminate the source code that leads to XSS; they only increase the difficulty for an attacker to succeed when such source code exists.

Now, if you were an attacker who found a chance for XSS, would you give up just because the difficulty is high? You probably wouldn’t; you would definitely look for a bypass. And why wouldn’t you? There are malicious uses for a successful XSS that can make you a lot of money! That’s why attackers will work to bypass a poorly configured CSP, and if it’s Trusted Types or a WAF, they will try every publicly known bypass from around the world. That’s how far an attacker will go.

Of course, there are cases where, as a result of increasing the difficulty, an XSS truly cannot be achieved. However, that is a matter of outcome. It’s better not to have the perception that you are safe just because you have multi-layered defenses. To close, let’s once again quote the words of OWASP³¹.

One final note: If deploying interceptors / filters as an XSS defense was a useful approach against XSS attacks, don’t you think that it would be incorporated into all commercial Web Application Firewalls (WAFs) and be an approach that OWASP recommends in this cheat sheet?

Recommended Countermeasures

Finally, let’s consider how we should approach XSS. To summarize everything we’ve discussed, the patterns of XSS that occur today are essentially as follows. Let’s list them again:

• A value that was thought to be safe was, in fact, not safe.
• A custom-built sanitizer was used but got bypassed, or an open-source sanitizer was used incorrectly.
• The defense mechanisms provided by a framework were not used correctly, or were simply not used at all.
• A lesser-known sink was embedded in a way that the framework does not protect against.
• A library was used without a proper understanding of its specifications.

Based on these patterns, the countermeasures we should take become clear. To avoid creating XSS vulnerabilities in this modern age, I believe the following points are crucial.

• Suspect all values. Programs are constantly changing and growing in complexity. It’s best to assume that accurately analyzing which values an attacker can control, and to what extent, is nearly impossible. A mindset of “no value is truly safe” is appropriate.
• When developing outside a framework, always use a widely-adopted open-source sanitizer to handle HTML. DOMPurify can be used on both the front-end and back-end and is recommended by OWASP. It’s a great choice. Also, whatever you use, do not modify the sanitized output in any way.
• When developing inside a framework, “correctly” understand and “always” use the provided defense mechanisms. First, you should properly understand the available security features by referring to the framework’s document. Then, you must use them wherever possible. If you can, it’s a good idea to introduce automated checks with linters in addition to code reviews.
• When handling URLs, check the scheme. Make sure that URLs with schemes like javascript: are not allowed.
• Do not dynamically generate scripts from input. JavaScript, in particular, has many complicated or unexpected grammars and behaviors, such as intervention in the prototype chain. A mechanism that generates and executes scripts based on user input is risky.
• Understand library behavior correctly. For any library generating HTML and JS, be sure to read its document thoroughly. In particular, information regarding security can often be found by searching for keywords like “warning,” “security,” “caution,” “deprecated,” and “preview”³². Please give it a try!

And after putting these methods into practice, here are the next steps you can take.

• Check for the presence of sinks with static analysis tools. While XSS sinks are diverse, they are also somewhat standardized, making inspection with static analysis tools like CodeQL or Semgrep effective. The ideal is to integrate this into your CI/CD pipeline and make it a condition for merging pull requests. If possible, running static analysis on bundled JavaScript can also help discover sinks hidden within libraries. Using a tool like Semgrep, which can scan only diff, can help keep execution times down. However, static analysis is not a silver bullet. Any rules may not be sufficient, so it is wise to avoid relying on it completely.
• Put risky modules in a sandboxed iframe. For example, it is effective to display the results of a WYSIWYG editor in an iframe and restrict what the iframe can do using sandbox and allow attributes.
• On top of that, utilize CSP and WAF. After implementing fundamental countermeasures, reducing risk with these additional layers is extremely effective.

In this post, we’ve taken a look at why XSS is still scary today. I hope this has helped you understand the background of how, no matter how much frameworks and sanitizers evolve, XSS can still arise from the smallest oversight.

Thank you for reading!👋