Cross-Site Scripting (XSS): How Attackers Exploit It and How to Stop It

A site can be well-designed, have a great URL and brand, and attract thousands of visitors every day, and still be riddled with a serious cross-site scripting (XSS) vulnerability.

The XSS (cross-site scripting) vulnerability is a type of web application security flaw that enables a visitor to a website to submit untrusted content that is interpreted as HTML or JavaScript by the target website. Depending on the vulnerability, an XSS attack can change the content of a page, trick a user into visiting a phishing page, disrupt an authenticated session, or reveal information.

Fortunately, there are well-known ways to prevent XSS attacks. Exposure can be significantly limited with proper output encoding, sanitization, secure DOM APIs, Content Security Policy (CSP), secure framework best practices, testing, and continuous maintenance.

However, the correct answer is going to vary according to the site. The baseline risk for a modern application built with framework-level auto-escaping is different to that of a legacy site built with hand-written templates and custom JavaScript.

For businesses, it makes a difference. Security of the website should be part of the development and maintenance process, rather than responding to attacks.

What is Cross-Site Scripting? Understanding XSS Attacks

XSS is a vulnerability that is triggered when an application accepts untrusted input and outputs it on a website without properly disarming the browser from rendering the input as code.

The untrusted data may come from:

• Search bars and URL parameters

• These are text boxes where a user can make comments or reviews

• User profile information

• Contact forms

• Customer support messages

• Content that is uploaded or created by users.

• Use of third-party data or integrations

The basic process is as follows:

Untrusted Input - Vulnerable Application - Unsafe Page Output - Browser Interprets Content - XSS Attack

According to MITRE's official definition, CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting) is the weakness: the failure to properly neutralize input before it is included in a web page. CWE-80 (Basic XSS), CWE-83 (Script in Attributes), and related weaknesses are also identified by MITRE.

How Does an XSS Attack Work?

An XSS injection can occur when a program does not enforce a separation between the data and executable code.

Suppose there is a web page with a user's query on their results page. If the application properly encodes the search term, the browser interprets the search term as text. Otherwise, if the application places it on an HTML page without proper protection, the attacker might be able to manipulate the browser's interpretation of the page.

The key takeaway is that it is not a good security measure to just cull out obvious words or characters. XSS can manifest itself in various forms, such as HTML, attributes, URL, JavaScript and DOM operations. An attack with the XSS attack can potentially lead to the attacker being able to:

There can be wider compromise, which can make the impact more serious, in the case of privileged users.

The sign of impact is dependent on the application architecture, protections in the browser, design of authentication and the privileges of the compromised user. XSS attacks can be especially harmful when the malicious content is accessed by a privileged user, MITRE points out.

XSS and CWE-79: Where Does It Fit?

Cross-Site Scripting is formally classified as CWE-79. XSS is also part of the current OWASP Top 10, namely class A05: Injection. It's of interest to note that some of the older security articles still refer to injection as A03:2021. Injection is the A05 of the 2025 OWASP edition. For the purposes of the OWASP mapping, it has been decided to assign all three of the CWEs (CWE-79, CWE-80, and CWE-83) to this category.

The classification is important as it reaffirms the following idea: XSS is essentially an injection problem. Untrusted data passes across a boundary and is interpreted as being different from what the developer expects.

The main types of XSS are reflected XSS, stored XSS and DOM-based XSS. There are other patterns that are important to know when conducting security evaluations: self-XSS and blind XSS.

Malicious input is generally provided as part of a query and is not stored in the application, but is reflected back to the resulting page. The source of the vulnerable data could be a URL parameter or search query.

The risk is higher if the affected application has sensitive functions or if users have high privileges.

1. Stored XSS

Stored XSS (also called persistent XSS) is when the attacker-controlled content is stored in an application and served to other users.

Common locations include:

• Comment sections

• Product reviews

• User profiles

• Forums

• Customer support systems

• Internal dashboards

Stored XSS might reach more victims as each one does not have to make the original request. A popular example of how pervasive XSS can be is the MySpace Samy worm from the past.

1. DOM-Based XSS

The DOM-based XSS occurs mostly at the client side. In this case, the server might not ever receive the malicious string. Instead, an attacker-controlled data is read by JavaScript in the browser and passed to an unsafe DOM operation.

If you want to use untrusted content, for example, using untrusted content in the innerHTML method can cause the browser to interpret it as HTML. MDN lists innerHTML as an injection sink and suggests more secure ways of using it for the desired content being merely text.

1. Self-XSS and Blind XSS

2. 

Self-XSS is a heavily social engineering attack. An attacker tricks the victim into copying or typing code into the browser console/other execution environment, rather than remotely injecting code into another user's page.

Blind XSS is not like that. The attacker deploys the content in some location where they have no direct view, such as an administrative dashboard, customer-service interface or log viewer. Content can play after an employee and/or administrator reads it. The differences illustrate the need to test internal workflows as well as public pages for XSS.

Real-World XSS Examples: What Businesses Can Learn

XSS is more than just a theoretical issue when building a website. You can see the history of events that remind you of the potential for great disruption when there are weaknesses in the security of the browser.

1. The MySpace “Samy” Worm (2005)

Samy Kamkar was the maker of the infamous “Samy” worm for MySpace in 2005. It leveraged a vulnerability in MySpace profiles that allowed it to be stored as XSS and spread as users were viewing affected content.

Kamkar's own account states that the worm gained access to over a million users within 20 hours. Many people felt that the outbreak had been reported, and that MySpace had been affected by it, as contemporary reporting also described the scope of the outbreak and the disruption to MySpace.

2. TweetDeck XSS Worm (2014)

TweetDeck was temporarily closed in 2014 when hackers exploited a vulnerability in the site that allowed them to launch an XSS attack. At the time, reports indicated that malicious content was run in the user's browser, and that the attack was self-propagating, which resulted in the automatic retweeting of tweets.

The incident highlighted one of the key principles of XSS – that the impact does not have to be limited to the page where the user finds the vulnerability. An attacker might be able to exploit a vulnerability in the vulnerable application to trigger an event that spreads quickly when automation is built-in or access to valuable functionality in the application is through the browser.

3. British Airways (2018)

The British Airways incident is often associated with articles about client-side attacks, but should not be treated as an actual CWE-79 DOM-based XSS incident.

British Airways was fined £20 million in 2020 by the UK Information Commissioner's Office for its cyber attack in 2018. The ICO claimed that over 400,000 customers were impacted and the airline had not adequately protected personal and financial data. It took over two months to detect the attack.

Malicious redirection and theft of customer information via compromised web infrastructure were responsible for the incident. It is more appropriate as a general web app security lesson, and as an example of how to protect sensitive online transactions and third-party/client side code, rather than being called out as a definite example of DOM-based XSS.

That is important for the broadcaster, when it comes to publishing security content – an incident may illustrate the business implications of the poor security of the web without necessarily having to be part of CWE-79.

How to Stop XSS: Real World XSS Prevention Strategies

The best way to prevent XSS is to apply multiple layers of defense, not just a single filter or security header.

The best lines of defense are:

• Context-aware output encoding

• Sanitization when applications must accept HTML

• Secure DOM APIs

• Content Security Policy

• Framework-level protections

• Ensure dependency and plugin security

• Developing and maintaining secure applications

• Output Encoding

The "output encoding" concatenates potentially meaningful HTML characters with their representation as ordinary characters that will be displayed in the browser.

For instance, if you are trying to output text, you can use the characters < and > as &lt; and &gt;.

The crucial word is context. Different contexts need different handling for HTML content, attributes, URLs, CSS and JavaScript.

The output encoding should then be performed at as close to the point of data rendering as possible, and be done in the technology's output encoding mechanisms. Input validation may still be useful for enforcing business rules, but should not be considered as the main line of defense against XSS.

Content Security Policy (CSP)

CSP is one of the most significant browser-side defenses that's available today. CSP enables a web page to specify what scripts, styles and other resources the browser may load or run. A well-crafted policy can then offer an additional defense if the application's first line of defense fails due to an XSS vulnerability.

MDN defines the output encoding/sanitization as first-line defenses and CSP as a second line of defense that can limit resources the browser accepts.

CSP can be extremely useful for apps that use more complex front-end architectures as it imposes restrictions using only the browser, rather than relying on application code.

Why X-XSS-Protection Isn't Sufficient Anymore

Where older XSS articles tend to provide bad advice. X-XSS-Protection is deprecated. It should not be described as ‘best practice'.

MDN explicitly states that the header is deprecated, and suggests using CSP. It's a browser filtering history that in modern browsers is mostly irrelevant, and MDN cautions that in certain situations, it could cause security issues.

The XSS Auditor was eliminated from Chrome, the XSS filter was never added to the header in Firefox, and Firefox's XSS filter was discontinued in Edge. The point of focus for current websites should be:

Safe DOM APIs: Use textContent Instead of innerHTML Where Appropriate

DOM APIs are selected depending on whether the developers need to insert text or HTML.

When an application just needs to display text, textContent is typically better than innerHTML. MDN points out that innerHTML treats input as HTML and may be an XSS injection sink if the input is attacker-controlled.

If an application really does need to take in a user-supplied HTML, then it should use an appropriate sanitization strategy, not just a different DOM method.

Is React vulnerable to XSS?

Modern frameworks like React and other frameworks, including Angular and Vue, have safer default settings and automatic escaping features, which reduce the risk of XSS, but do not remove XSS as a class of vulnerabilities.

The technology stack is thus an essential factor in evaluating the risk of a website. Just because a business joins the React trend doesn't mean that their website will be secure. Also, it should not presume that a WordPress or legacy application is by itself dangerous.

The question is how the application actually deal with untrusted data.

XSS vs SQL Injection: Difference between XSS and SQL Injection

The difference between SQL injection and XSS is that with SQL injection the attacker is injecting data somewhere that is not a Web page, whereas in XSS the attacker is injecting data into a Web page that is being interpreted.

An XSS attack is aimed at the web page and browser. SQL injection attacks a layer in the application that interfaces with the database. Simply put, XSS vs SQL injection is as follows:

They are both injection vulnerabilities, and the defenses are different. As part of a website security review, both the browser and server/database side risks should be evaluated. To learn more about attacks based on databases, check out our SQL injection guide.

XSS and CSRF: Why They Are Not the Same

XSS is the ability to run an attacker's script within the context of a trusted website. Cross-Site Request Forgery (CSRF) is a type of attack that tries to trick a user's browser into submitting an unwanted request to a site to which the user is already authenticated.

The difference can be boiled down to this:

XSS: attacker-controlled script runs in the context of the trusted site.

CSRF: victim's browser is tricked into making an unwanted request by using his/her authentication.

However, they can interact! One other point to consider is that a serious XSS vulnerability can affect some of the assumptions made with regards to CSRF defenses; therefore, taking a holistic view of web application security is important for businesses.

Protect Your Business Website From XSS Vulnerabilities With Xcentric Services

The potential cost to a business for an XSS vulnerability goes beyond a single line of code. A hacked site can impact the confidence of customers, lead generation, e-commerce transactions, internal operations, and brand reputation. The threat could be even greater when a website is handling customer accounts, payment data or other sensitive information for customers.

The first step to securing a website is to appreciate how the site is developed.

A modern framework that will escape automatically might be a solid base. If the application is a "legacy" one with handwritten templates and plugins that are a bit outdated and a lot of custom JavaScript, then it might need a much more detailed review.

That's where a professional digital and development company can come in handy. Xcentric Services is all about digital strategy, website building, design, e-commerce building and website support services. Security should be considered as part of the development, testing, updates and long-term maintenance, not a standalone technical action.

A technical review that focuses on security can be beneficial if your website is using custom code, third-party integrations, has a CMS, or has a JavaScript-heavy interface and/or older templates; it helps uncover vulnerabilities before they become issues for your customers

If you want to continue to get protected, check out Xcentric Services website support and maintenance service. By have your website maintained reguarly, you can ensure that your framework, plugins, integrations and custom components remain up to date with the latest security practices.

Conclusion

The fact that modern web application development is heavily dependent on dynamic content, client-side functionality and complex third-party services made into web apps is an ominous trend that makes cross-site scripting (XSS) a significantly important web application security concern.

To understand XSS, one must first learn about the different types of XSS. There are different types of XSS: Reflected XSS, stored XSS, DOM-based XSS, self-XSS, blind XSS.

A layered approach to XSS prevention is used. Context-aware output encoding, sanitization, safe DOM APIs, CSP, secure framework practices and continuous testing are key priorities for businesses.

Above all, don't use old information. X-XSS-Protection is an outdated option; CSP is the current option for the browser. But although frameworks like React lower the risk of XSS, they're not immune to XSS attacks.