“What is the most common vulnerability you still find in 2026?”

It is a question we ask our penetration testers regularly.

While Cross-Site Scripting (XSS) may not necessarily be the most common vulnerability we find, it is one that continues to stand out — both because of its potential impact and because, with the maturity of modern web application frameworks, we arguably shouldn’t still be finding it as often as we do.

Yet, in 2026, we still do.

What is Cross-Site Scripting?

Cross-Site Scripting, better known as XSS, occurs when an application allows untrusted content to be interpreted and executed within a user’s browser.

The impact can vary enormously.

At the lower end, a finding such as self-XSS may have little practical security impact. At the other end of the spectrum, XSS can allow an attacker to execute malicious code in another user’s session, impersonate that user, access information available to them or perform actions with their privileges. OWASP notes that successful XSS attacks can result in account impersonation, sensitive-data theft and other serious consequences.

This becomes particularly concerning within authenticated web applications.

If a low-privileged user can exploit an XSS vulnerability in a way that targets an administrator or another highly privileged user, the consequences can become significantly more serious. PortSwigger similarly notes that when the compromised user has elevated privileges, XSS can potentially allow an attacker to compromise the application and its users.

In the right circumstances, what initially appears to be a client-side vulnerability can therefore become a pathway to privilege escalation and broader application compromise.

So why are we still finding it?

This is perhaps the most surprising part.

Modern web application frameworks have been around for well over a decade, and many provide developers with built-in mechanisms that make safely handling dynamic content considerably easier.

OWASP specifically recommends modern frameworks such as React, Vue, Angular and Svelte because of the protections they provide when handling dynamic data – while warning that developers still need to avoid unsafe APIs and implementation patterns that can reintroduce XSS risk.

React is a good example.

By default, developers have safer mechanisms for rendering content. However, React also provides an escape hatch called dangerouslySetInnerHTML, which allows raw HTML to be inserted directly into the DOM.

The name is fairly telling.

React’s own documentation warns that the feature should be used with “extreme caution” because passing untrusted data to it can introduce an XSS vulnerability.

In other words, in many modern applications, developers may actually need to bypass or work around protections already provided by the framework before certain XSS vulnerabilities become possible.

That is what makes continuing to find them so frustrating.

CSP is improving – but implementation matters

There has been another positive change: we are increasingly seeing applications implement Content Security Policy (CSP) headers.

A well-designed CSP provides an additional layer of defence against XSS by controlling which scripts and other resources a browser is permitted to execute or load. OWASP recommends CSP as a defence-in-depth control alongside secure development practices rather than as a replacement for them.

However, simply having a CSP header doesn’t necessarily mean an application has strong protection.

We still regularly see policies containing directives such as:

'unsafe-inline'

and

'unsafe-eval'

These directives permit behaviours that CSP is often intended to restrict. OWASP’s current Web Security Testing Guide specifically warns that unsafe-inline significantly weakens XSS protections, while unsafe-eval permits dynamic code evaluation and increases the risk of CSP bypass.

So while seeing CSP implemented more frequently is encouraging, the strength of the policy matters just as much as its presence.

Could XSS eventually disappear?

Hopefully.

Modern frameworks already provide developers with many of the tools required to prevent XSS. Strong Content Security Policies can add another important defensive layer. Secure coding practices, appropriate output encoding and sanitisation can further reduce the attack surface.

The technology exists.

The challenge is using it correctly and consistently.

XSS vulnerabilities can have some of the most significant impacts we encounter during web application penetration testing, particularly when privileged users can be targeted.

And in 2026, we are still finding them far too often.

Our hope is that, as secure framework usage and CSP implementation continue to mature, XSS becomes a vulnerability we eventually stop finding altogether.