What is Subresource Integrity (SRI)?

Subresource Integrity (SRI) is a browser security feature that verifies the integrity of files loaded from third-party sources. It protects websites from tampered scripts or stylesheets—helping developers and security teams ensure external content hasn’t been altered maliciously.

What Is Subresource Integrity (SRI)?

Subresource Integrity (SRI) is a web security standard that allows browsers to check that resources fetched from third-party CDNs or other domains haven’t been manipulated. By adding a cryptographic hash to the resource’s HTML tag, developers can ensure the file’s integrity before it’s executed in the user’s browser.

How It Works

SRI uses cryptographic hash functions (like SHA-256) embedded in HTML tags to validate external files. Here’s how it works:

1. A developer adds a script or link tag that includes an integrity attribute with the file’s hash value.
2. When a browser requests the file, it computes its own hash of the downloaded content.
3. If the hash matches the one in the integrity attribute, the file is executed or rendered. If not, it’s blocked.

Example:

Who’s at Risk

Without SRI, websites that load JavaScript or CSS from external sources are vulnerable to:

• Supply chain attacks – if the third-party resource is compromised.
• CDN hijacking or misconfiguration – attackers may inject malicious code into CDN-hosted libraries.
• Content spoofing – malicious resources impersonating legitimate files.

Teams at risk include:

• DevOps and frontend engineers using CDN-based assets.
• Organizations subject to compliance (PCI DSS, HIPAA) that require resource integrity checks.
• Enterprises managing large-scale third-party scripts.

Real-World Examples

• In 2018, a popular JavaScript library on a CDN was modified with cryptojacking code. Sites loading the script without SRI unknowingly served malware to users.
• Magecart attackers often inject malicious scripts into third-party services—SRI could block execution if hashes don’t match.

How to Detect or Prevent It

Detect

• Use browser developer tools or automated scanners to inspect third-party scripts.
• Enable CSP (Content Security Policy) reports to catch unexpected script behavior.

Prevent

• Always include integrity and crossorigin attributes when referencing third-party resources.
• Automate hash generation with build tools or CDNs that support SRI.
• Monitor third-party dependencies regularly for changes or updates.

How Feroot Helps

Feroot’s Client-Side Security Platform helps detect unauthorized changes and monitor third-party scripts in real time. While SRI protects static files, Feroot tracks dynamic behaviors, including script injection, unauthorized API calls, and form field tampering. Together, they form a powerful defense-in-depth strategy.

FAQ

Is SRI required by compliance standards like PCI DSS 4.0?

Yes, Requirement 6.4.3 of PCI DSS 4.0 calls for integrity checks on third-party scripts—SRI is one way to meet that need. Learn more.

Can I use SRI with dynamic scripts or inline code?

No. SRI only works with static, externally hosted resources. For dynamic scripts, use additional controls like CSP and behavior monitoring.

What happens if the file’s content changes after I publish the hash?

The browser will block the resource. You must update the hash in your HTML to match the new content.

Do all browsers support SRI?

Most modern browsers support SRI, including Chrome, Firefox, Edge, and Safari.