What Is Cross-Site Script Inclusion (XSSI)?

On this page
  1. How does XSSI work?
  2. How do you prevent XSSI?

Cross-site script inclusion (XSSI) exploits a gap in the same-origin policy: while the policy stops a page from reading a cross-origin response, it happily lets a page include one as a <script>. If a victim endpoint returns sensitive data in a script-executable form, an attacker’s page can include it and capture the data — a subtle leak that predates and complements CORS.

How does XSSI work?#

The <script src> tag can load cross-origin, and the browser executes what comes back. If a logged-in user’s data endpoint returns JavaScript — or JSON that can be coerced into executing — an attacker’s page can harvest it:

  1. The attacker’s page includes <script src="https://victim.example/userdata">.
  2. The victim’s browser sends the request with their cookies.
  3. The response (containing the victim’s data) is executed as script in the attacker’s page.
  4. By pre-defining objects or overriding constructors, the attacker captures the values.

Classic targets are legacy JSONP endpoints and dynamic scripts that embed user-specific data.

How do you prevent XSSI?#

DefenseEffect
Anti-hijacking prefix ()]}')Response can’t be parsed as a script
Require a custom header / POSTCross-origin <script> can’t send it
Correct JSON content typeNot executed as JavaScript
Avoid JSONPRemoves the executable-data pattern

The prefix trick is elegant: prepending )]}' to a JSON response makes it a syntax error if included as a script, while your own client strips the prefix before parsing.

XSSI is a same-origin-policy edge case for data leakage. More at the Web Security hub.

Frequently asked questions#

What is cross-site script inclusion?

XSSI is an attack where a malicious site includes a victim endpoint as a script via a script tag — which the same-origin policy permits — to read sensitive data returned in a script-executable format. If a dynamic endpoint returns JavaScript or a script-parseable structure containing user data, the attacker’s page can capture it.

How do you prevent XSSI?

Do not return sensitive data in a directly script-includable form. Require a custom header or POST for data endpoints, return JSON with a proper content type (not executable), and prepend an anti-JSON-hijacking prefix like )]}' to responses so they cannot be parsed as a script. CSRF-style protections also help.

Sources & further reading