Investigating Subresource Integrity (SRI): Should You Really Add It to JavaScript from External CDNs?

In code that loads JavaScript or CSS from an external CDN, you may come across something like the following.

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

Even if you vaguely know that the integrity attribute is related to security, some questions remain.

Isn't serving over HTTPS enough?
Is it needed even when installing via npm?
How does it differ from CSP?
Does it mean anything for apps built with Next.js or Vite?
Why is it rarely seen in general web development even though it seems important?

So I looked into the Subresource Integrity (hereafter SRI) specification, the attacks it can actually prevent, past incidents, and its relationship with modern build environments.

To state the conclusion first, SRI is not an all-purpose security feature.

However, when loading fixed-version JavaScript or CSS from an external CDN, it is still a relatively low-cost and highly effective measure.

On the other hand, it is hard to apply to third-party scripts whose contents change frequently, such as Google Tag Manager, ads, analytics tools, and A/B testing tools. Ironically, the riskier the script, the harder it is to use SRI with it.

In this article, rather than declaring "you must always use SRI," I organize the kinds of setups where adoption is most worthwhile.

What Is SRI

SRI is a mechanism in which the browser verifies whether the content of a fetched JavaScript or CSS file matches the hash value written in the HTML.

For example, suppose there is a script tag like this.

<script
  src="https://cdn.example.com/library.min.js"
  integrity="sha384-BASE64_HASH"
  crossorigin="anonymous"
></script>

The browser processes it roughly in the following order.

Fetch the file specified in src
Compute a hash from the fetched content
Compare it with the hash in the integrity attribute
Execute the JavaScript only if they match
Fail the load if they do not match

If the hash does not match, the browser does not just issue a warning and run it anyway. The resource is treated as a network error: JavaScript is not executed, and CSS is not applied.

In other words, SRI is verification performed on the browser side of "is this file really the content we approved in advance?"

The W3C SRI specification also defines it as a mechanism by which the user agent verifies that a fetched resource has not been unexpectedly manipulated.

What Does It Look Like in Practice

When loading Bootstrap and the like from an external CDN, it looks like this.

<link
  rel="stylesheet"
  href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css"
  integrity="sha384-..."
  crossorigin="anonymous"
/>

<script
  src="https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.bundle.min.js"
  integrity="sha384-..."
  crossorigin="anonymous"
></script>

The main supported hash algorithms are the following three.

SHA-256
SHA-384
SHA-512

In practice, SHA-384 is commonly used.

To generate a hash for a local file, you can compute it like this, for example.

openssl dgst -sha384 -binary library.min.js | openssl base64 -A

Prepend sha384- to the output and specify it in the integrity attribute.

integrity="sha384-generated-Base64-string"

Why Is `crossorigin="anonymous"` Needed

When using SRI on a resource from another origin, you normally also specify crossorigin="anonymous".

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

For cross-origin requests with SRI, the browser fetches the response using CORS.

The CDN serving the file also needs to return a CORS response header such as the following.

Access-Control-Allow-Origin: *

This is because if hash checking were freely allowed on cross-origin opaque responses, an attacker might be able to use whether the hash matches or not to infer the content of another origin.

Therefore, if the CDN does not support CORS, an SRI resource may fail to load even with the correct hash specified.

Is SRI Unnecessary if You Have HTTPS

This was the first thing I wondered about.

HTTPS encrypts the communication channel and prevents eavesdropping and tampering in transit. That makes SRI seem unnecessary.

But what HTTPS and SRI protect is actually a bit different.

What HTTPS Protects

HTTPS mainly guarantees the following.

The communication partner is the host corresponding to the certificate
The content is hard to snoop on in transit
The content is hard to rewrite in transit

What SRI Protects

SRI verifies the following.

The fetched file matches the content the developer approved in advance

For example, if the legitimate CDN itself is compromised and returns malicious JavaScript over a legitimate HTTPS connection, everything is normal as far as HTTPS is concerned.

The communication partner is the legitimate CDN, and the channel is encrypted.

But the content of the returned file has changed into something malicious.

If SRI was specified in this case, the browser can detect the hash mismatch and stop execution.

The following framing makes it easy to understand.

HTTPS is a mechanism for trusting the communication channel, and SRI is a mechanism for verifying the delivered content.

They are not substitutes for each other, but complementary.

What SRI Can Prevent

SRI is effective basically in situations where "the URL is correct, but the content returned from that URL has changed."

When the CDN Is Compromised

If a file on an external CDN is rewritten by an attacker, it no longer matches the SRI hash, so the browser stops execution.

This is the representative use case for SRI.

When the Origin of an External Service Is Hijacked

If a third-party service's server or account is compromised and malicious JavaScript is served from the same URL, it can be detected as long as the hash on the HTML side has not been updated.

CDN Misdelivery and Misconfiguration

The target is not only malicious attacks.

Even if a different file is returned due to a CDN misconfiguration or cache inconsistency, SRI stops the load.

When the Content of a Fixed-Version URL Is Changed

For example, suppose you use a URL like the following.

https://cdn.example.com/library/1.2.3/library.min.js

The version is fixed in the URL.

But there is a nonzero possibility that the origin later swaps out the file at the same URL.

SRI pins the actual file content rather than the URL, so it can detect such changes as well.

DNS Hijacking and Cache Poisoning

Even if you are redirected to another server or other content through a DNS attack or CDN cache poisoning, the file is blocked if the returned file differs from the prior hash.

However, it cannot prevent this if the HTML itself is rewritten at the same time.

Summary by Threat

Threat / incident	SRI effectiveness	Reason
Tampering with JavaScript on a CDN	High	If the content changes, the hash won't match
Compromise of an external delivery provider	High	Detectable even if malicious files are returned from the same URL
CDN misdelivery	High	Unexpected content is blocked regardless of the cause
Replacement of a fixed-version URL	High	Pins the content, not the URL
CDN cache poisoning	Conditional	Effective when only the delivered content changes
DNS hijacking	Conditional	Effective when the HTML stays safe and only the external resource is swapped
Man-in-the-middle attacks	Conditional	HTTPS is the first line of defense. Adds verification if the content changes
npm package compromise	Generally ineffective	Compromise occurs in the build process before it reaches the browser
Tampering with the HTML itself	Ineffective	Both `src` and `integrity` can be rewritten
XSS	Ineffective	A different problem from integrity verification of external files
CSRF	Ineffective	Not a mechanism for preventing request forgery

What SRI Cannot Prevent

To understand the scope of SRI's responsibility, it may be easier to look at what it cannot prevent.

Tampering with the HTML Itself

The SRI hash value is written in the HTML.

So if an attacker can rewrite the HTML, they can replace both of the following at the same time.

<script
  src="https://attacker.example/malware.js"
  integrity="sha384-correct-hash-computed-by-the-attacker"
></script>

SRI treats the HTML as the root of trust, so it has no effect if the HTML itself is compromised.

Officially Published Malicious Versions

Suppose the maintainer of a dependency library is compromised and a malicious version is officially published to npm or a CDN.

If a developer fetches that file and updates to a new hash without checking the content, SRI passes as normal.

What SRI verifies is "does it match the approved content," not "is that code safe."

npm Package Compromise

In cases such as ua-parser-js and event-stream, where malicious code was included in the npm package itself, SRI is generally of no use.

This is because the malicious code is fetched from npm and incorporated into your own JavaScript as part of the build output.

From the browser's point of view, it is a legitimate file of your own.

In this area, the following measures are needed.

lockfiles
npm audit
Dependabot or Renovate
Package signing and provenance
Dependency review
Protection of the CI/CD environment
Verification of build artifacts

XSS and CSRF

SRI is a feature that verifies the content of external resources.

It does not directly prevent XSS, where scripts are injected from user input, or CSRF, where unauthorized requests are made to be sent.

For XSS countermeasures, CSP, output escaping, Trusted Types, and so on are central.

How Do npm Lockfiles Differ from SRI

package-lock.json and pnpm-lock.yaml also store integrity information for dependency packages. In npm's package-lock.json, for example, there is a value like this.

{
  "integrity": "sha512-..."
}

The format is similar to SRI, but the timing of verification is different.

Lockfile Integrity

Lockfile integrity verifies, at the time the npm package is installed, that the fetched tarball is what was expected.

In other words, the point it protects is the following.

npm registry
  ↓
Development environment / CI

Browser SRI

Browser SRI verifies at the time the user fetches JavaScript or CSS in production.

CDN / Web server
  ↓
User's browser

Both use a similar hash format but protect different stages.

Mechanism	When verified	Main purpose
lockfile integrity	At package install time	Integrity and reproducibility of package retrieval
SRI	When the browser fetches the resource	Verifying the content of delivered files

Therefore, "we have a lockfile so SRI is unnecessary" is not necessarily true.

However, in a setup where libraries fetched via npm are bundled yourself and served from your own domain, the additional benefit of SRI is smaller than when reading directly from an external CDN.

How Does It Differ from Filenames with a Content Hash

With Vite and Webpack, a content hash is sometimes added to built filenames.

assets/index-a8f45c2d.js

At first glance, this also looks like file content verification.

But the main purpose is cache control.

When the file content changes, the filename changes too, making it easier to get browsers to fetch the new file.

index-a8f45c2d.js
↓ content changed
index-b71d903a.js

The browser does not check the hash portion of the filename against the actual file content.

If different content is returned from the same URL due to an attacker or a CDN misconfiguration, a content-hashed filename alone cannot detect it.

Summarized, the difference is as follows.

Mechanism	Main role
Filename with content hash	Cache invalidation and versioning
SRI	Verification of actual file content by the browser

Differences Between CSP and SRI

The technology most often compared with SRI is Content Security Policy (CSP).

CSP

CSP restricts which origins a page can load scripts, images, and so on from.

Content-Security-Policy: script-src 'self' https://cdn.example.com

This example allows scripts from your own origin and cdn.example.com. However, if cdn.example.com itself is compromised and malicious code is served from the same host, host-based CSP alone will allow it.

SRI

SRI checks whether the content of a file fetched from an allowed host is as expected.

So it can be summarized as follows.

CSP controls "where things can be loaded from," and SRI verifies "what the loaded content is."

Because their roles differ, combining them is effective.

For screens that need high security, combine the following.

HTTPS
CSP
SRI
Reducing external scripts
Trusted Types
Monitoring dependencies

Should You Use `require-sri-for`

In the past, CSP had a directive called require-sri-for.

Content-Security-Policy: require-sri-for script style

It was a feature intended to make SRI mandatory for script and style.

However, due to standardization and browser implementation issues, it is now removed and deprecated. You should avoid depending on it in new implementations.

On the other hand, from 2025 onward, implementation of the new Integrity-Policy header is progressing.

Integrity-Policy: blocked-destinations=(script)

Integrity-Policy is a new mechanism for requiring integrity verification on target resources and for collecting violations through the Reporting API.

Support for scripts is progressing in Chrome 138 and Firefox 145 and later.

SRI itself became a W3C Recommendation in 2016, but extensions to related specifications continue even in 2026.

Rather than an "old, finished technology," it is more accurate to think of it as being at a stage where the core functionality is mature and enforcement and monitoring features around it are being added.

Did SRI Help in Past Incidents

The Polyfill.io Supply Chain Attack

In 2024, a problem occurred in which malicious JavaScript was served from Polyfill.io.

It is a typical supply chain attack in which an external JavaScript delivery service was compromised and abused, and malicious JavaScript could run in visitors' browsers even though the sites using it had not changed their code.

In such cases, if the target file had fixed content and SRI had been set beforehand, the unauthorized replacement might have been detected.

However, Polyfill.io was a dynamic service that changed what it returned depending on the User-Agent and requested features.

Since the content varies per user even at the same URL, it is not a good match for SRI, which specifies a fixed hash.

This case shows both the effectiveness and the limits of SRI.

Strong against replacement of fixed files
Hard to apply to services whose content changes dynamically

Ticketmaster and Third-Party JavaScript

In the Ticketmaster case, unauthorized code was inserted into the JavaScript of a third-party chat service used on the payment page, and customer data was leaked.

If the target JavaScript was a fixed file loaded from an external URL and the HTML side had not been tampered with, SRI might have prevented it.

However, depending on the actual loading method and update method, SRI may not have been applicable, so we cannot go so far as to assert that "SRI would surely have prevented it."

The British Airways Magecart Breach

At British Airways, JavaScript that steals payment information was injected into the website.

In this case, the site's own scripts or HTML itself may have been compromised, and in a situation where an attacker can change the HTML, the SRI can be rewritten too.

So it is hard to think that SRI alone could have prevented it.

ua-parser-js and event-stream

These are cases where malicious code was published in the npm packages themselves.

The compromised code is incorporated into the app at build time, so it is outside the scope of browser SRI.

Even among "supply chain attacks," some are addressed by SRI and some are not.

Runtime file replacement on an external CDN
→ SRI is effective

Compromise of npm / CI / build process
→ Generally not preventable by SRI

Use Cases Where SRI Is Especially Useful

Loading Fixed-Version Libraries from an External CDN

This is the most straightforward case.

For example, libraries like the following.

Bootstrap
jQuery
Prism.js
Highlight.js
Font Awesome
Fixed UMD builds of React

If the URL and file content are fixed, you can operate by simply changing the hash on updates.

Since the benefit is large relative to the adoption cost, adding SRI is in principle a reasonable decision.

Static HTML, Landing Pages, and Documentation Sites

Even for static sites without a build environment, you can adopt it just by adding integrity to external CDN tags.

It is especially well suited to sites like the following.

GitHub Pages
Static landing pages
Pages managed by a CMS
Documentation sites
Corporate sites with infrequent updates

Using External Libraries in WordPress

In WordPress as well, you can add integrity and crossorigin using hooks that output scripts and styles.

If you use fixed files from an external CDN, adoption is worthwhile.

However, if a theme or plugin automatically updates the URL, you need to be careful about consistency with the hash.

Admin Screens and Payment Screens

On pages that handle admin privileges or personal information, you should reduce third-party JavaScript itself as much as possible.

If you still need to load external resources, the priority of SRI goes up.

On payment screens in particular, the compromise of just one third-party script can lead to input data being stolen.

Use Cases Where SRI Is Hard to Use

Google Tag Manager, Ads, and Analytics Tools

The content of these scripts is updated frequently even at the same URL.

If you add SRI, the hash will mismatch at every update and the script will stop.

For this reason, SRI often cannot be realistically operated with Google Analytics, ad tags, tag managers, A/B testing tools, and so on.

This is quite a structural problem.

The riskier a third-party script, the more frequently its content changes, and so the harder it is to apply SRI.

In this area, countermeasures other than SRI are important.

Remove unnecessary tags
Restrict who can add tags
Restrict destinations with CSP
Isolate with iframes or sandbox
Monitor changes to third-party scripts
Don't load them on payment screens

Dynamic Widgets and Chat Tools

For chat, customer support, personalization, A/B testing, and the like, the delivered content may vary per user or per configuration.

In that case, the content cannot be pinned with a single hash value.

Module Federation

In Webpack Module Federation, remoteEntry.js and subsequent chunks are loaded dynamically at runtime.

Applying SRI is possible in itself, but the following mechanisms are needed.

Pinning the version of remoteEntry
Distributing hash values
Setting integrity when dynamically inserting scripts
Managing hashes of subsequent chunks
Consistency of deployments between host and remote

Compared with simple CDN loading, the operational difficulty is considerably higher.

Is It Enough to Add SRI Only to the Entry Point for ES Modules

Suppose you have an ES Module like the following.

<script
  type="module"
  src="/assets/main.js"
  integrity="sha384-..."
></script>

If main.js imports other modules, the entry point's SRI is not automatically propagated to all dependent modules.

import "./feature.js";
import("./lazy.js");

The initial fetch of main.js is verified, but child modules are not verified with the same hash. As a way to give dependent modules integrity information too, the integrity key in import maps has been standardized.

<script type="importmap">
{
  "imports": {
    "app": "/assets/main.js"
  },
  "integrity": {
    "/assets/main.js": "sha384-...",
    "/assets/feature.js": "sha384-...",
    "/assets/lazy.js": "sha384-..."
  }
}
</script>

Actual build output contains many chunks, so when adopting SRI for all chunks in Vite, Webpack, Next.js, and so on, a mechanism to automatically generate hashes at build time is almost essential.

Does Compression Break SRI

HTTP compression with gzip or Brotli is normally compatible with SRI.

The browser uses the resource content after decompressing the transfer compression, so whether the same JavaScript is sent with gzip or Brotli normally does not require changing the SRI hash.

The problem is processing that changes the JavaScript or CSS content itself during delivery.

For example, features like the following.

Automatic minification on the CDN
Rewriting of JavaScript
Code transformation per User-Agent
Swapping files by region
Content changes through A/B testing
Per-user optimization at the same URL

If the content of the code the browser finally receives changes, the hash will not match.

Compatibility problems may also occur with features that change how script tags or JavaScript are loaded, such as Cloudflare's Rocket Loader.

Files that use SRI are in principle safer if they satisfy the following conditions.

Always return the same content for the same URL
Do not transform code on the CDN side
Serve as immutable files
Use URLs with a version or content hash

Adoption Also Adds Availability Problems

SRI does not execute a resource if the hash does not match.

That is correct behavior for security, but it can lead to outages operationally.

For example, suppose there is a deployment inconsistency like the following.

New HTML was delivered
The HTML contains the new hash
Old JavaScript remains at the CDN edge

In this case, the hash may not match and the app may fail to start.

Conversely, the same applies when old HTML references new JavaScript.

Be especially careful in the following setups.

Blue-Green Deployment
Rolling deployments
Deploying HTML and static assets separately
Long HTML cache
CDN cache purges taking a long time
A large number of dynamic chunks

When adopting SRI, you need to think not only about security but also about deployment atomicity and cache strategy.

Fallback During CDN Outages

If loading from the CDN fails, there is a method of switching to a self-hosted version.

<script>
  function loadLocalLibrary() {
    const script = document.createElement("script");
    script.src = "/assets/library.min.js";
    script.integrity = "sha384-LOCAL_HASH";
    script.crossOrigin = "anonymous";
    document.head.appendChild(script);
  }
</script>

<script
  src="https://cdn.example.com/library.min.js"
  integrity="sha384-CDN_HASH"
  crossorigin="anonymous"
  onerror="loadLocalLibrary()"
></script>

However, adding more fallbacks also adds the following problems.

It is hard to distinguish a CDN outage from an SRI mismatch
The fallback destination also needs to be allowed in CSP
Multiple hashes need to be managed
Failure analysis becomes complex
The fallback destination may be outdated

It is practical for loading a few fixed libraries, but not realistic to apply to the large number of chunks of a large SPA.

Should You Adopt It with React, Vite, and Next.js

React

React itself has no feature for managing SRI.

If you load React directly from a CDN UMD build, it is worth adding SRI as an external CDN use.

On the other hand, if you install React via npm and bundle with Vite or Webpack, it is handled on the build tool side.

Webpack

For Webpack, webpack-subresource-integrity is the representative option.

It can generate SRI including dynamic chunks, but you need to check compatibility with your Webpack version and HTML generation plugin.

Vite

It is hard to say that Vite itself has well-integrated built-in support for general-purpose automatic SRI, and the use of community plugins is the main approach.

Candidates include the following.

vite-plugin-manifest-sri
vite-plugin-sri-gen
Other SRI generation plugins

However, the target differs by plugin.

Adds integrity directly to the HTML
Adds hashes to the manifest
Also supports modulepreload
Supports even dynamic chunks

At adoption time, you need to check the maintenance status and what is generated.

Next.js

Next.js has experimental support for hash-based CSP using SRI for the App Router.

However, it is an experimental feature and has limitations in combination with build methods, routers, and static generation.

The value of adding SRI to all the regular chunks that Next.js serves itself is not as clear as for fixed libraries on an external CDN.

If the HTML and assets are on the same deployment platform and in the same trust boundary, an attacker who can change the HTML can change the SRI along with it.

On the other hand, it becomes meaningful in setups such as serving static assets from a separate CDN, inserting edge transformations, or coordinating with a strict CSP.

Adoption Decisions by Setup

Setup	Recommendation	Judgment
Load fixed-version JS/CSS from an external CDN	High	The representative use of SRI. Add it in principle
Load `latest` from an external CDN	Low	Better to pin the version before even thinking about SRI
Load Bootstrap from a CDN in static HTML	High	Easy to adopt and the benefit is clear
Load fixed CDN libraries in WordPress	Medium to high	Effective if you can manage hash updates
Load fixed external scripts on a payment screen	High	Reducing external scripts comes first. Use SRI if needed
SPA built in-house with packages from npm	Low to medium	Smaller additional benefit than with external CDN use
Serve content-hashed files from your own CDN	Low to medium	Meaningful when trust boundaries or delivery paths are separate
Google Tag Manager and ad tags	Low	Content changes frequently and cannot be pinned
Analytics and A/B testing tools	Low	Dynamic delivery and SRI don't mix well
Module Federation remotes	Low to medium	Feasible but hash distribution and deployment management are hard
Regular Next.js chunks	Medium	Depends on the delivery setup and CSP requirements
Admin screens and personal-information input screens	High	Reduce external scripts, and use SRI on the fixed assets that remain

So, Should You Add SRI to External CDNs

Within the scope of what I investigated, adding it in principle seems a reasonable decision when the following conditions are met.

You load JavaScript or CSS from an external origin
The URL is pinned to a specific version
The same URL always returns the same content
The CDN supports CORS
You can also change the hash when updating

For example, a load like the following.

<script src="https://cdn.example.com/library/latest.js"></script>

For this, it is better to first consider pinning the version.

<script
  src="https://cdn.example.com/library/1.2.3/library.min.js"
  integrity="sha384-..."
  crossorigin="anonymous"
></script>

If you pin the version and then add SRI, both the URL and the content can be pinned.

On the other hand, it is better not to force SRI onto things like the following.

Analytics scripts whose content changes frequently
Tag managers
Ad delivery tags
Widgets whose content changes per user
Remotes that are resolved dynamically
Services that return different code per User-Agent

In those cases, you need to consider other defenses instead of SRI.

Priorities in Practice

SRI is not something you adopt on its own and be done.

As for priorities, it is realistic to think of them as follows.

1. Remove Unnecessary Third-Party Scripts

The safest thing is not to load them in the first place.

On admin screens, payment screens, and personal-information input screens in particular, you should review whether marketing tags and chat tools really need to be loaded.

2. Set Up HTTPS and CSP

HTTPS is a prerequisite.

CSP restricts where things are loaded from and where data can be sent, making unauthorized script injection and data exfiltration harder.

3. Add SRI to Fixed External Resources

This is an area where SRI is easy to apply and the benefit is high.

4. Protect npm Dependencies and the Build Process

Lockfiles, dependency updates, auditing, and CI/CD protection are needed separately from SRI.

5. Monitor and Isolate Dynamic Third-Party Scripts

When you cannot use SRI, combine iframes, sandbox, CSP, change monitoring, permission control, and so on.

What I Felt After Investigating

Before looking into SRI, my impression was "a somewhat old security feature where you just add a hash to external CDN tags."

But in reality, the problem SRI tries to solve still exists today.

Loading external JavaScript on a web page is close to handing your page's level of privilege to that origin.

An external script can do things like the following on the page.

Read the DOM
Read form input
Access client data other than cookies
Send requests to APIs
Send data to external servers
Load additional scripts

So the SRI mindset of "allow only this exact content of this file," rather than just "trust it because it's a well-known CDN," is reasonable.

On the other hand, Google Tag Manager, ads, analytics, A/B testing, chat, and so on, which are high-risk on the modern web, change their content frequently and so are hard to apply SRI to.

I felt that the reason SRI is not used much is not that the technology is meaningless, but that modern third-party scripts have moved away from SRI's assumption of "loading a fixed file."

Summary

The greatest value of SRI can be condensed into the following sentence.

The browser can verify that a resource fetched from a trusted origin really matches the content approved in advance.

SRI is effective against CDN tampering, compromise of external origins, misdelivery, and replacement at fixed URLs.

It cannot prevent tampering with the HTML itself, XSS, npm package compromise, CI/CD compromise, or maliciously official releases.

In practice, I think the following judgments are easy to follow.

Add SRI in principle to fixed-version JS/CSS from external CDNs
For a typical SPA bundled in-house with npm, the priority is lower than with external CDN use
On admin and payment screens, first reduce third-party scripts
For dynamic scripts where SRI cannot be used, use CSP, isolation, and monitoring
Don't use SRI as a substitute for overall security measures

SRI is not "a feature absolutely required on every website."

But where it is easy to apply, it is still a defense that gives a clear benefit at low cost.

Being clear about which delivery paths you trust and which stages' tampering you are trying to prevent matters more than whether you added SRI.