67. Subresource Integrity: What It Is, Why It Matters, and When It Really Applies

Part of the Zehr.net Conversation Series

Website security reports can be useful, but they can also make every warning sound equally urgent. One item that often appears is Subresource Integrity, usually shortened to SRI. At first glance, it sounds complicated. In practice, the idea is fairly simple: if a website loads an outside file, the browser can be told exactly what that file should look like. If the file changes unexpectedly, the browser refuses to use it.

67 Subresource Integrity: What It Is, Why It Matters, and When It Really Applies

What Is Subresource Integrity?

A “subresource” is a file that a webpage depends on after the main HTML page loads. Common examples include JavaScript files, CSS stylesheets, fonts, icons, tracking scripts, widgets, or code libraries.

Subresource Integrity is a security feature that lets the browser verify that a loaded file has not been changed from the version the website owner expected. This is done with a cryptographic hash — a long fingerprint of the file’s contents.

For example, instead of simply loading a script like this:

a site can load it with an integrity value:

The browser downloads the file, calculates its fingerprint, and compares it to the fingerprint in the HTML. If they match, the file is allowed to run. If they do not match, the browser blocks it.

Why Does SRI Exist?

SRI is mainly designed for one situation: a website uses files hosted somewhere else.

That “somewhere else” might be a public CDN, a third-party plugin provider, a marketing platform, a chat widget, analytics software, or another outside service. The site owner may trust that service, but the site owner does not fully control it.

If that outside file is compromised, replaced, or modified in a harmful way, every website loading it could be affected. SRI reduces that risk by saying, in effect:

“Only run this outside file if it is exactly the file I approved.”

How Could SRI Be Exploited Without Protection?

The real concern is not that an attacker magically changes your HTML page. The concern is that an external dependency changes after your site has already trusted it.

For example:

• A public JavaScript library on a CDN is compromised.
• A third-party widget provider is hacked.
• A file is changed by mistake and behaves differently than expected.
• A supply-chain attack modifies a popular library used by many websites.

JavaScript is especially important because it can do powerful things inside a browser. A malicious script could potentially alter page behavior, capture form entries, redirect visitors, inject unwanted content, or interfere with how the page works.

External Files vs. Internal Files

This is where many security reports need human interpretation.

External Files

External files are loaded from outside the website’s own domain, such as:

https://cdn.example.com/library.js
https://fonts.example.com/font.css
https://thirdparty-service.com/widget.js

These are the files where SRI usually matters most. The website owner is depending on someone else’s server to deliver safe, unchanged code.

Internal Files

Internal files are served from the same website, such as:

/css/styles.css
/js/gallery.js
/includes/navigation.js

For internal files, SRI is usually less important because the file is already under the same site owner’s control. If an attacker can change your internal JavaScript or CSS files, the bigger problem is not the absence of SRI. The bigger problem is that the site or server has been compromised.

That does not mean internal files are unimportant. It means they are usually protected through good server security, file permissions, backups, updates, HTTPS, access control, and careful coding — not primarily through SRI.

When SRI Is Most Useful

SRI is most useful when all of the following are true:

• The page loads JavaScript or CSS from another domain.
• The file is expected to stay the same.
• The site does not control the server hosting that file.
• A change to that file could affect visitors or forms.

Good examples include fixed-version CDN files, such as a specific version of a JavaScript library.

When SRI Can Be Awkward

SRI is not always a simple “turn it on everywhere” feature.

If a third-party file changes often, the hash will change too. When the hash changes, the browser will block the file until the website’s HTML is updated with the new hash.

That can be good for security, but it can also break a feature if the outside provider updates the file without notice. This is one reason SRI works best with fixed-version files, not constantly changing scripts.

What About Fonts, Analytics, and Widgets?

Many websites load outside resources for convenience. Fonts, analytics tools, embedded widgets, maps, social media scripts, and marketing tools are common examples.

From a practical small-business website perspective, each outside dependency should be questioned:

• Do we really need it?
• Can we host it locally instead?
• Is it worth the added dependency?
• Does it affect privacy, speed, accessibility, or security?
• If it stays external, would SRI be appropriate?

In many cases, the cleanest answer is not “add SRI to everything.” The cleanest answer may be: reduce outside dependencies where possible.

A Practical Zehr.net View

For many small-business sites, SRI should be understood as part of a bigger philosophy:

• Keep websites simple.
• Avoid unnecessary third-party scripts.
• Host important files locally when practical.
• Use HTTPS.
• Keep server access controlled.
• Use SRI where external scripts or stylesheets truly need it.

A security scanner may flag missing SRI as if every missing hash is equally serious. But the real-world risk depends on what file is being loaded, where it comes from, what it does, and whether the site owner controls it.

Simple Example: Better External Script Loading

A stronger external script reference may look like this:

The important pieces are:

• src — where the file comes from.
• integrity — the approved fingerprint of the file.
• crossorigin — helps the browser properly verify cross-origin resources.

Bottom Line

Subresource Integrity is a valuable browser security feature, especially for externally hosted JavaScript and CSS files. It helps protect visitors if an outside file changes unexpectedly or is tampered with.

But SRI is not a replacement for good server security, careful coding, updates, backups, and reducing unnecessary third-party dependencies. It is one layer in a larger security approach.

For small-business websites, the best first step is often to review every external file the site loads. If the site does not need it, remove it. If the site does need it and the file is stable, consider SRI. If the file is internal and already controlled by the site owner, focus first on the broader security of the server and website.

That is the real value of a security report: not panic, but better questions — and steady, practical improvements.