Subresource Integrity (SRI) is a W3C security specification that enables browsers to verify that files fetched from external sources (CDNs, third-party hosts) have not been modified or tampered with. By including a cryptographic hash of the expected file content in the HTML tag that loads the resource, browsers can compare the hash of the downloaded file against the expected value and refuse to execute it if they don't match.

For DeFi frontends, SRI is a critical defense against supply chain attacks and CDN compromises. If an attacker gains access to a CDN or hosting provider and modifies a JavaScript file to include wallet-draining code, SRI causes browsers to block the tampered file entirely rather than executing it. This would have prevented or mitigated attacks like the Bybit hack, where a modified JavaScript chunk served from AWS S3 manipulated transaction data.

How SRI Works

SRI is implemented by adding an integrity attribute to <script> and <link> tags:

1<script 
2  src="https://cdn.example.com/app.js"
3  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
4  crossorigin="anonymous">
5</script>

When the browser downloads the file from the CDN, it computes the SHA-384 hash of the received content and compares it to the hash specified in the integrity attribute. If the hashes match, the script executes normally. If they don't match — indicating the file has been modified — the browser blocks execution entirely and reports a network error.

SRI supports multiple hash algorithms (SHA-256, SHA-384, SHA-512) and allows specifying multiple hashes for the same resource to support hash algorithm migration. The crossorigin="anonymous" attribute is required for SRI checks on cross-origin resources, as the browser needs access to the raw file content to compute the hash.

SRI in DeFi Security

DeFi frontends rely heavily on external resources: JavaScript bundles from CDNs, web3 libraries, wallet connector packages, and UI frameworks. Each externally loaded resource is a potential injection point:

CDN compromise is a high-impact attack vector where an attacker modifies files hosted on a content delivery network. Without SRI, every user who loads the page receives the malicious version. With SRI, the tampered file fails the integrity check and is blocked, protecting all users whose browsers support SRI (all modern browsers do).

Hosting infrastructure attacks target the servers or cloud storage (S3 buckets, GCP buckets) where frontend assets are deployed. The Bybit attack exploited exactly this vector: compromised AWS S3 hosting served modified JavaScript. SRI hashes embedded in the HTML would have caused browsers to reject the modified JavaScript chunk.

Build pipeline compromise is partially mitigated by SRI. If an attacker injects malicious code during the build process but the deployment pipeline computes SRI hashes from the original (clean) build artifacts, the tampered files will fail integrity checks. However, if the attacker compromises the pipeline at a point where they can also update the integrity hashes, SRI alone won't help.

Implementation in Modern Build Pipelines

Modern frontend build tools can automate SRI hash generation:

Webpack supports SRI through the webpack-subresource-integrity plugin, which automatically computes and injects integrity attributes for all emitted assets. Vite and other bundlers have similar plugins available.

For DeFi applications, the recommended approach is:

1. Generate SRI hashes as part of the production build process
2. Store hashes separately from the built assets (different storage, different access controls)
3. Inject hashes into HTML templates at deployment time
4. Monitor for SRI failures in production as potential indicators of compromise

Limitations

SRI only protects externally loaded resources referenced in HTML with integrity attributes. It does not protect against:

• Inline script injection — Code injected directly into the HTML page bypasses SRI. Content Security Policy (CSP) addresses this vector.
• Dynamic script loading — Scripts loaded at runtime via document.createElement('script') can bypass SRI unless the application explicitly sets integrity attributes on dynamically created elements.
• First-party compromise — If the attacker modifies both the script and the HTML page containing the integrity hash, SRI provides no protection. This is why SRI works best when the HTML and the scripts are served from different infrastructure with separate access controls.

SRI and CSP work best together as complementary defenses: CSP restricts which sources can load scripts, while SRI ensures that scripts from allowed sources haven't been tampered with.