Cybersecurity glossary
What is Cross-Site Script Inclusion (XSSI)?
Learn what Cross-Site Script Inclusion (XSSI) is, how including JSON as script can leak data cross-site, which defenses like JSON hijacking protections help, and how to ship safe APIs.
Definition
Cross-Site Script Inclusion (XSSI) is an attack in which a malicious page includes another site’s sensitive URL as a script resource so the browser fetches authenticated or confidential content and interprets it as JavaScript—often enabling data theft from JSON or script-like responses.
Why XSSI matters
Developers often assume confidential JSON is safe because browsers block cross-origin reads via XHR without CORS. Cross-Site Script Inclusion (XSSI) uses a different door: the <script> tag. If a sensitive endpoint returns content the browser will execute as script—and cookies still attach—the attacker page can arrange to learn secrets through side effects.
Historical “JSON hijacking” against array responses is the best-known flavor, but the broader issue is serving sensitive data in an executable form.
How XSSI works
Locate a sensitive URL
Find an authenticated GET endpoint returning user data, tokens, or private JSON.
Include it as a script
Attacker page uses script src pointing at the victim URL.
Browser sends credentials
If cookies are eligible cross-site, the request is authenticated as the victim.
Response executes as script
If the body is JavaScript-shaped, the attacker context can trap data via overrides or JSONP callbacks.
Data leaves the victim origin
Secrets are exfiltrated without a traditional CORS read.
Risky response shapes
JSONP endpoints
Designed to be script-included; catastrophic for private data.
JavaScript MIME on APIs
Sensitive content labeled as executable script invites inclusion.
Historically hijackable JSON
Certain array/object forms were abused with constructor tricks in older browsers.
Cookie-authenticated GETs
Private data on GET without extra request proof is easier to include cross-site.
Defenses that work
| Control | Effect |
|---|---|
| Never use JSONP for sensitive data | Removes intentional script-inclusion API style |
| Serve JSON as application/json | Clarifies non-script intent; pair with other controls |
| XSSI prefixes / non-executable wrappers | Breaks direct script execution of JSON bodies |
| SameSite cookies | Reduces credentialed cross-site script subrequests |
| Fetch Metadata allowlists | Reject unexpected cross-site script navigations to APIs |
| Require custom headers / tokens | Script tags cannot easily attach anti-CSRF headers |
API checklist
- Audit authenticated GET endpoints for script-inclusion abuse.
- Retire JSONP for anything private.
- Return application/json and avoid executable wrappers around secrets.
- Apply SameSite=Lax/Strict on session cookies where possible.
- Reject API requests with Sec-Fetch-Dest: script when appropriate.
- Prefer Authorization headers or anti-CSRF proofs over cookie-only GET APIs for sensitive reads.
- Add regression tests that attempt cross-site script inclusion against private endpoints.
- Review legacy browsers only if you still support them; defenses still matter for modern stacks.
The practical takeaway
Cross-Site Script Inclusion (XSSI) steals data by loading another site’s sensitive response as a script from an attacker page. CORS alone does not close this door.
Keep private data out of executable script forms, harden cookies and Fetch Metadata checks, and treat JSONP as incompatible with confidential APIs.
Related security terms
Cross-Origin Resource Sharing (CORS)
API access control model that does not by itself stop classic script-tag inclusion.
Same-Origin Policy (SOP)
Browser boundary that script inclusion partially bypasses for readable execution side effects.
Content-Type
Correct content types help distinguish JSON from executable script.
Fetch Metadata
Sec-Fetch-* headers that can help reject unexpected cross-site script loads.
Frequently asked questions
What is XSSI in simple terms?
An attacker’s page loads your sensitive URL with a script tag. The browser sends cookies and tries to run the response as JavaScript, which can leak data if the response is script-shaped.
Is XSSI the same as XSS?
No. XSS injects script into a victim site. XSSI abuses inclusion of another site’s response as script from an attacker page.
Why doesn’t CORS stop XSSI?
Classic <script src> loads are not CORS-gated the same way XHR/fetch are. A script tag can still fetch and execute cross-origin script responses.
What responses are dangerous?
JSON that is also valid JavaScript (historically arrays), JSONP, or any sensitive content served with a JavaScript MIME type.
How do you prevent XSSI?
Do not serve confidential data as executable script, use non-executable JSON prefixes, require non-simple headers or anti-CSRF tokens for sensitive GETs, apply SameSite cookies, and use Fetch Metadata checks.
Is JSONP safe?
JSONP is inherently script inclusion. Avoid JSONP for authenticated or sensitive data.
Do SameSite cookies help?
Yes for cookie-authenticated endpoints: Strict/Lax can prevent cookies on cross-site script subrequests, reducing XSSI usefulness.
References
Explore authoritative guidance and frameworks related to cross-site script inclusion (xssi).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.