SRI and CORS Requirements

Technical Deep Dive & Specifications

The Vulnerability: The Cryptographic Oracle Attack

Why did browser vendors and the W3C mandate that SRI fails without CORS?

Imagine an attacker hosting https://evil-attacker.com. Suppose a user visits the attacker's site while logged into their online bank (https://mybank.com).

The bank has a sensitive JSONP or JavaScript endpoint: https://mybank.com/api/account-details.js which renders:

var account = { balance: "$14,500.00", user: "Alice" };

Under normal Same-Origin Policy rules, evil-attacker.com can load this script via <script src="https://mybank.com/api/account-details.js">, but the attacker cannot directly read the source code text.

Now imagine if the browser allowed SRI without CORS:

1. evil-attacker.com guesses possible account balance strings ("$10,000.00", "$10,001.00", etc.).
2. The attacker calculates the SHA-384 hash for each guess.
3. The attacker dynamically creates <script src="https://mybank.com/api/account-details.js" integrity="sha384-[GUESS_HASH]">.
4. If the guess is wrong, the browser throws an onerror event.
5. If the guess is correct, the browser fires onload!

+------------------------------------------------------------------------------------+
|                HOW SRI WITHOUT CORS WOULD BECOME A DATA-THEFT ORACLE               |
+------------------------------------------------------------------------------------+
|                                                                                    |
|  Attacker guesses: "balance: $14,500" -> Hash: sha384-abc                          |
|  Injects: <script src="https://bank.com/api" integrity="sha384-abc">              |
|  Result: 🛑 onerror (Guess wrong)                                                  |
|                                                                                    |
|  Attacker guesses: "balance: $14,501" -> Hash: sha384-xyz                          |
|  Injects: <script src="https://bank.com/api" integrity="sha384-xyz">              |
|  Result: ✅ onload (MATCH FOUND! Attacker now knows the user's private balance!)    |
|                                                                                    |
+------------------------------------------------------------------------------------+

By turning SRI into a cryptographic oracle, an attacker could extract private user data, CSRF tokens, or personal identifiers across origins.

To eliminate this vulnerability, the W3C SRI specification mandates: If a resource is fetched from a different origin and includes an integrity attribute, the fetch mode must be CORS.

The crossorigin Attribute Values

To satisfy the CORS requirement on <script> and <link> elements, you must supply the crossorigin attribute:

📌 Best Practice: For static public CDNs (cdnjs, jsDelivr, unpkg, Google Fonts), always use crossorigin="anonymous".

CDN Server Header Requirements

For SRI to succeed, the CDN server hosting the script or stylesheet must respond with the appropriate CORS headers:

HTTP/2 200 OK
Content-Type: application/javascript; charset=utf-8
Access-Control-Allow-Origin: *
Vary: Origin, Accept-Encoding
Cache-Control: public, max-age=31536000, immutable

Why Vary: Origin is Critical on the CDN

If a CDN edge server caches a response for an asset requested without CORS (e.g. from a client that didn't pass Origin), and then serves that cached response (which lacks Access-Control-Allow-Origin) to a client performing an SRI CORS check, the SRI check will fail.

The Vary: Origin header instructs intermediate proxies and CDNs to cache separate copies based on the presence and value of the incoming Origin request header.

💻 Interactive Code Playground

Starter Code

Line-by-Line Code Breakdown

• Lines 8–14 (<link rel="stylesheet"...): Loads Font Awesome icons from Cloudflare CDN. It includes both integrity and crossorigin="anonymous". Cloudflare responds with Access-Control-Allow-Origin: *, allowing the browser to read the stylesheet bytes and compute the SHA-512 digest.
• Lines 32–36 (<script src="..." integrity="..." crossorigin="anonymous">): Loads Axios. Because crossorigin="anonymous" is declared, the browser sends the HTTP request with mode cors and excludes credentials. The downloaded bytes are hashed and compared with the sha512- string.
• Lines 38–51 (<script>...): Confirms runtime execution. If crossorigin had been omitted, modern browsers would reject the fetch immediately with a NetworkError.

Expected Browser Render Output

+-----------------------------------------------------------------------+
| 🛡️ Subresource Integrity + CORS Check                                 |
| This page demonstrates valid cross-origin asset loading with CORS.   |
|                                                                       |
| ✅ Axios v1.6.7 successfully loaded with CORS & SRI verification!     |
+-----------------------------------------------------------------------+