Subresource Integrity (SRI): Secure Your Scripts 2026

What Subresource Integrity Is and Why It Matters in 2026

Subresource Integrity is a W3C standard that lets browsers verify the integrity of externally loaded resources. You add an integrity attribute containing a cryptographic hash of the expected file content to a <script> or <link> tag. Before the browser executes the script or applies the stylesheet, it computes the hash of the downloaded file and compares it to the stored value. If both match, the resource runs — otherwise the browser discards it and reports an error (MDN).

The relevance stems from the reality of modern websites: 92% of all pages load at least one third-party resource (HTTP Archive Web Almanac 2024), and the median page requests 20 external scripts totaling around 449 KB (HTTP Archive Web Almanac 2024). Scripts account for 30.5% of all third-party requests by content type (HTTP Archive Web Almanac 2024). Each of these scripts is a potential entry point: if a provider's server is compromised or the file is altered in transit, foreign code runs with full privileges in your page context.

SRI addresses a very specific threat class: supply-chain attacks via compromised or swapped scripts. ENISA ranks traditional software supply-chain attacks among the ten most common threat categories — they accounted for 10.6% of analyzed incidents (ENISA Threat Landscape 2025, 4,875 incidents examined). That is precisely where SRI fits: it does not protect against a hacked CDN account, but it prevents the code tampered with there from causing harm in your visitors' browsers.

How an SRI Hash Works Technically

An SRI hash is a Base64-encoded cryptographic fingerprint of the file content, prefixed with an algorithm identifier. The browser downloads the resource, computes the hash on the fly, and aborts execution as soon as the value differs (MDN). The allowed prefixes are sha256, sha384, and sha512 — conformant browsers must support all three (W3C SRI). In practice, sha384 is recommended as a balanced compromise between security and performance.

<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8K"
  crossorigin="anonymous"></script>

<link
  rel="stylesheet"
  href="https://cdn.example.com/style.css"
  integrity="sha384-9ndCyUa8q2y2bI3rvT2gI3lyf3v6dGmF"
  crossorigin="anonymous">

You can specify multiple hashes — for example for different algorithms — separated by spaces. The browser uses the strongest one it supports. This enables a smooth migration from weaker to stronger hash functions without locking out older clients. Important: SRI protects static, immutable files. For resources that change dynamically on the server, the hash would have to be regenerated on every change — SRI is unsuitable here.

Supply-Chain Attacks: The Threat SRI Addresses

Web skimming — also known as Magecart — is the most prominent attack form SRI helps against. Attackers inject JavaScript into payment or form pages to harvest credit card and login data directly in the browser. According to a RiskIQ analysis, a Magecart attack is attempted every 16 minutes (RiskIQ). The threat is growing: Recorded Future recorded a 103% increase within six months in the 2024/2025 period (Recorded Future).

What makes this attack class so insidious is that it completely bypasses classic server-side defenses. A web application firewall, a hardened server, and regular backups do not help when the malicious code is delivered legitimately through an embedded third-party script and executed exclusively in the visitor's browser. The shop operator's server never 'sees' this code — it lives in the source of a file on a foreign CDN. This is precisely the gap a client-side integrity check closes: SRI moves control to where the code is actually executed. Given that skimming campaigns like CosmicSting temporarily hit 5 to 30 stores per hour (Sansec), this shift is not a theoretical luxury but a practical necessity for any operator embedding foreign scripts.

The economic dimension is substantial: the average cost of a data breach in 2024 was USD 4.88 million (IBM Cost of a Data Breach 2024). For a German online shop, a record harvested via foreign code means not only reputational damage but also a potential reporting obligation under Art. 33 GDPR.

The Reality: SRI Is Common but Barely Used

The adoption numbers paint a paradoxical picture. On one hand, SRI is present on many sites: 23.2% of desktop pages and 21.3% of mobile pages use at least one integrity attribute (HTTP Archive Web Almanac 2024). On the other hand, actual coverage is minimal: the median is just 3.23% of scripts per page checked against a hash — and this figure has remained virtually unchanged since 2022 (HTTP Archive Web Almanac 2024).

Even the sites with the highest coverage protect only 12.5% of their scripts via SRI at the 90th percentile (HTTP Archive Web Almanac 2024). Most protected resources come from CDNs — the leaders are www.gstatic.com (35%), cdnjs.cloudflare.com (7%), and code.jquery.com (5–6%) (HTTP Archive Web Almanac 2024). Notably, Shopify dropped SRI in favor of the integrity attribute of import maps (HTTP Archive Web Almanac 2024) — an indication that the protection mechanism is evolving.

SRI Working Together with CSP and Other Headers

SRI is not a lone wolf. It delivers its full protective effect in combination with other security mechanisms — above all the Content Security Policy. While SRI secures the integrity of known, allowed scripts, CSP controls which sources may be loaded at all. The two complement each other rather than replace one another.

• CSP require-sri-for approach: CSP can enforce that scripts and styles only load with a valid integrity hash — turning SRI from a recommendation into a requirement.
• script-src with nonces: CSP authorizes legitimate scripts via one-time tokens, while SRI additionally verifies their content. Together they exclude both injection and tampering.
• Strict-Transport-Security (HSTS): Enforces HTTPS and prevents scripts from being swapped over an unencrypted connection in transit.
• Mixed-content avoidance: Complements SRI, because mixed content opens an unencrypted supply chain in which tampering becomes possible in the first place.
• X-Content-Type-Options: Prevents MIME sniffing so a resource is not interpreted as an executable script against its declaration.

If you have already cleanly configured your HTTP security headers, you should treat SRI as the logical next building block. Only the combination of transport security (HTTPS/HSTS), source control (CSP), and integrity verification (SRI) forms a multi-layered concept against script-based attacks. It is also worth examining the certificate trust layer: continuous evaluation of Certificate Transparency logs uncovers mis-issued certificates, which can be a prerequisite for undetected man-in-the-middle tampering with scripts.

SRI as a Compliance Building Block: PCI DSS 4.0 and GDPR

SRI is no longer just a nice-to-have. With PCI DSS 4.0, integrity verification of scripts on payment pages became effectively mandatory. Requirement 6.4.3 calls for an inventory of all scripts used on payment pages, in which each resource is authorized, integrity-checked, and justified (PCI Security Standards Council). Requirement 11.6.1 adds the obligation to detect and alert on unauthorized changes to headers and scripts of the payment page (PCI Security Standards Council).

SRI also contributes in the GDPR context. Art. 32 GDPR requires 'appropriate technical and organizational measures.' If SRI prevents tampered third-party code from exfiltrating personal data, it demonstrably reduces the risk of a reportable data breach. In combination with a documented data protection impact assessment for web tracking, this creates robust evidence of technical safeguards.

Monitoring SRI Coverage: Why Setting It Once Is Not Enough

The biggest practical problem with SRI is not the setup but the maintenance. An integrity attribute is only as good as its hash — and that hash is valid for exactly one file version. When a CDN provider updates its library, a build process changes the file, or a developer switches the script source, one of two things happens: either the script breaks because the old hash no longer matches, or the attribute is removed in the heat of the moment — and protection silently disappears.

This is exactly where continuous monitoring comes in. There are two complementary layers: first, the detection of new, unprotected external scripts — resources added without an integrity attribute. Second, the detection of changed externals, where the delivered content of a third-party file has changed compared to the last check. Both are early warning signs of a potentially compromised supply chain.

The stagnation of SRI coverage — unchanged since 2022 at around 3.23% of scripts per page (HTTP Archive Web Almanac 2024) — shows that manual maintenance is rarely sustained over time in practice. The reason is humanly understandable: an integrity attribute set once is quickly forgotten in day-to-day work, and after the first broken script following a CDN update, developers are tempted to remove the protection entirely rather than recompute the hash on every update. Continuous monitoring reverses this incentive pattern: instead of treating SRI as tedious manual labor, the state of script protection becomes a measurable metric that surfaces on every deviation — and that is exactly what prevents the silent slide into an unprotected state.

SRI Checklist and Automated Header Monitoring

An effective SRI strategy combines careful setup with continuous control. The following checklist summarizes the most important steps — from initial implementation to ongoing monitoring.

1. Inventory external scripts — capture all <script> and <link> tags with a foreign origin. A security scan provides the complete overview including dynamically loaded resources.
2. Set integrity + crossorigin="anonymous" for every static third-party resource — preferably with a sha384 hash (W3C SRI).
3. Regenerate the hash on every version change — a hash is valid for exactly one file version; outdated hashes break the script.
4. Add CSP to turn SRI from a recommendation into a requirement and to exclude unwanted sources on principle.
5. Monitor unprotected and changed externals — new scripts without integrity and content-deviating files are early warning signs.
6. Prioritize payment and form pages — here PCI DSS 6.4.3/11.6.1 requires a script inventory plus change detection (PCI Security Standards Council).

The XICTRAQ security score rates your website partly based on the security headers in place and the protection of external resources. If a protection mechanism disappears, a new unprotected script appears, or a critical header configuration changes, you receive a timely notice via alerting notifications — by email, Slack, Discord, or Telegram. In combination with ongoing security monitoring, securing your script supply chain turns from a one-time action into a permanently monitored state.

Frequently Asked Questions About Subresource Integrity