Securing Your Website With Subresource Integrity

Why Subresource Integrity Matters for Modern Web Security

Modern web applications rely on an intricate web of external resources--JavaScript libraries, CSS frameworks, fonts, and assets loaded from content delivery networks and third-party servers. While this approach improves performance and reduces development time, it introduces significant security risks. If an attacker compromises a CDN or intercepts a resource in transit, they can inject malicious code into your application with the same privileges as your own code.

Subresource Integrity (SRI) provides a robust defense mechanism that ensures every external resource loaded by your website matches an expected cryptographic signature, protecting your users from supply chain attacks and unauthorized modifications. This security layer works alongside HTTPS and Content Security Policy to create comprehensive protection for modern web applications built with frameworks like Next.js.

What You'll Learn

• The supply chain vulnerability problem and why third-party resources pose risks
• How cryptographic hashing verifies resource integrity
• Implementation patterns using integrity and crossorigin attributes
• Hash generation techniques using OpenSSL, Node.js, and online tools
• CDN requirements and CORS configuration for SRI
• Automated workflows with webpack-subresource-integrity plugin
• Performance considerations and best practices

The Supply Chain Vulnerability Problem

The modern web development ecosystem depends on dozens of external resources. A typical commercial website loads JavaScript libraries for DOM manipulation, charting libraries for data visualizations, font services for typography, and various analytics scripts. Each of these represents a potential attack vector--if an attacker compromises any single CDN or injects code into a third-party resource, they gain the ability to execute arbitrary JavaScript in your users' browsers, as documented by the OWASP Foundation.

Consequences of Supply Chain Attacks

• Credential theft through injected keyloggers or session hijacking
• Form data manipulation redirecting submissions to attacker servers
• Website defacement without server access
• Cryptomining using your visitors' computational resources
• Malware distribution through trusted code execution

Traditional defenses like HTTPS protect data in transit but don't prevent a CDN operator (or an attacker who has compromised the CDN) from serving modified content. Unlike vulnerabilities in your own code that you can patch quickly, a compromised third-party resource affects every site that depends on it--potentially thousands of websites simultaneously.

According to the OWASP Foundation, Subresource Integrity enables browsers to verify that resources match expected cryptographic hashes before execution, preventing modified code from running even if the delivery infrastructure has been compromised.

How Subresource Integrity Works

Subresource Integrity leverages cryptographic hash functions to create a fingerprint of each external resource. You calculate a SHA-256, SHA-384, or SHA-512 hash of the resource content, encode this hash in base64, and include it as an integrity attribute on the HTML element that loads the resource. When the browser fetches the resource, it recalculates the hash of the received content and compares it against your specified value. Only if the hashes match exactly does the browser execute the script or apply the stylesheet.

Integrity Attribute Format

The integrity attribute follows a specific format including the hash algorithm and base64-encoded hash value:

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

The prefix (sha384-) indicates which algorithm browsers should use, while the long string is the actual cryptographic digest. The W3C SRI Specification defines these hash algorithm prefixes that specify the verification method. SHA-384 and SHA-512 are recommended for new implementations due to their stronger cryptographic properties compared to SHA-256.

Browser Verification Process

1. Browser encounters script/link element with integrity attribute
2. Fetches resource from specified URL
3. Computes cryptographic hash of received content
4. Compares computed hash against integrity attribute value
5. If hashes match: resource executes/applies normally
6. If hashes don't match: browser blocks resource and reports network error

This verification happens before execution, ensuring no modified code can run even if an attacker has compromised the delivery infrastructure.

As documented in the MDN SRI Implementation Guide, the crossorigin attribute is required for cross-origin SRI verification to work properly.

Implementing Subresource Integrity

Basic HTML Implementation

Adding SRI to your HTML requires the integrity attribute on script and link elements. Include the crossorigin attribute for resources loaded from different origins, as browsers require CORS headers to perform integrity verification on cross-origin resources.

JavaScript with SRI:

<script
 src="https://code.jquery.com/jquery-3.7.1.min.js"
 integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yc/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
 crossorigin="anonymous"
></script>

Stylesheet with SRI:

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

The crossorigin="anonymous" attribute instructs browsers to perform the integrity check using CORS semantics. Without it, browsers may skip the integrity check for cross-origin resources, defeating SRI's protection.

According to MDN Web Docs on Subresource Integrity, Subresource Integrity applies to script and link elements with specific rel values (stylesheet, preload, modulepreload), ensuring comprehensive protection for all externally loaded code and styles.

For websites built with modern frameworks, implementing SRI is an essential part of securing your web applications against supply chain attacks.

Generating Integrity Hashes

Creating integrity hashes requires computing the cryptographic digest of resource files and encoding in base64. Several tools make this process straightforward for different workflows.

Command Line with OpenSSL

# SHA-384 hash (recommended)
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

# SHA-512 hash (strongest)
cat FILENAME.js | openssl dgst -sha512 -binary | openssl base64 -A

# SHA-256 hash (wide compatibility)
cat FILENAME.js | openssl dgst -sha256 -binary | openssl base64 -A

For remote URLs:

curl -s https://cdn.example.com/library.js | openssl dgst -sha384 -binary | openssl base64 -A

Node.js Programmatic Generation

const crypto = require('crypto');
const fs = require('fs');

function generateIntegrityHash(filePath, algorithm = 'sha384') {
 const hash = crypto.createHash(algorithm);
 hash.update(fs.readFileSync(filePath));
 return `${algorithm}-${hash.digest('base64')}`;
}

console.log(generateIntegrityHash('./dist/bundle.js'));

Online Tool

The SRI Hash Generator accepts a resource URL and returns the complete integrity attribute with crossorigin. It also checks CORS support for CDN resources.

As outlined in the MDN SRI Implementation Guide, these hash generation methods provide flexibility for different development workflows and security requirements.

Automating hash generation in your build pipeline ensures consistent SRI protection across all deployment environments.

CDN Requirements and CORS Integration

Understanding CORS Requirements

Content Delivery Networks must properly implement Cross-Origin Resource Sharing for SRI verification to work. When a browser loads a resource with an integrity attribute from a different origin, it performs a CORS check alongside integrity verification. The CDN must include Access-Control-Allow-Origin headers in its response, as required by the OWASP Foundation guidelines.

CORS Header Configuration

For public CDN resources (the standard pattern):

Access-Control-Allow-Origin: *

For restricted deployments:

Access-Control-Allow-Origin: https://yourdomain.com

The CORS requirement ensures browsers can distinguish between a CDN that intentionally serves resources to your site and a malicious actor attempting to serve modified content. Most major CDNs already support CORS, but verify before relying on SRI for production resources.

Verifying CDN CORS Support

Use the SRI Hash Generator tool's CORS check to verify a CDN's CORS support. If a CDN lacks CORS headers, consider finding an alternative CDN, self-hosting the resource, or negotiating CORS enablement with the provider.

According to the MDN SRI Implementation Guide, the crossorigin attribute is required alongside integrity for proper cross-origin resource verification.

When selecting a CDN for your web development projects, ensure they support CORS to enable SRI protection.

Automated SRI with Build Tools

webpack-subresource-integrity Plugin

For webpack-based projects, the webpack-subresource-integrity plugin automates hash generation and injection into built assets. This is essential for production deployments where manual hash maintenance would be impractical, as recommended by MDN Web Docs.

Installation:

npm install --save-dev webpack-subresource-integrity

Configuration:

import SriPlugin from 'webpack-subresource-integrity';

export default {
 output: {
 crossOriginLoading: 'anonymous',
 },
 plugins: [
 new SriPlugin({
 hashFuncNames: ['sha384'],
 enabled: process.env.NODE_ENV === 'production',
 }),
 ],
};

The crossOriginLoading option is essential--it tells webpack to use anonymous CORS mode for cross-origin chunks, required for browser integrity verification on dynamically loaded modules.

Next.js Integration

For Next.js applications, add integrity attributes to external scripts loaded through the Script component:

import Script from 'next/script';

<Script
 src="https://cdn.example.com/library.js"
 integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yc/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
 crossOrigin="anonymous"
 strategy="afterInteractive"
/>

Combining SRI with Content Security Policy for Defense in Depth

While SRI protects against modified content, Content Security Policy controls which sources can load resources in the first place. Together, they provide layered security: CSP prevents loading from unauthorized origins, while SRI ensures that even resources from allowed sources haven't been modified. This defense-in-depth approach is essential for production applications handling sensitive data.

Next.js supports CSP headers through middleware, allowing you to enforce strict source policies while using SRI for hash verification. Configure CSP to whitelist specific CDN domains, then use SRI to verify the integrity of all resources loaded from those domains. If an attacker compromises an allowed CDN, the modified content will fail SRI verification and won't execute.

As documented in the Next.js Content Security Policy Guide, combining these headers provides robust protection against both injection attacks and supply chain compromises.

Integrating automated SRI generation into your web development workflow ensures security best practices are applied consistently across all projects.

Performance Considerations

Verification Overhead

The performance impact of SRI verification is negligible in practice. Hash verification happens during the normal fetch pipeline, overlapping with network I/O. Modern processors include hardware acceleration for SHA operations, making cryptographic computation extremely fast, as noted in MDN's implementation guidance.

For perspective, hash verification for a typical minified JavaScript bundle (100-200KB) takes well under a millisecond on modern devices. The network transfer and JavaScript parsing/execution dominate loading time by orders of magnitude. Tests comparing pages with and without SRI show no statistically significant difference in load times, Time to Interactive, or other performance metrics.

Build Pipeline Impact

The primary consideration is build-time overhead. Computing hashes for every build artifact adds a small amount to build duration. For most applications, this is acceptable--a few seconds increase at most.

Optimization strategies:

• Cache build artifacts and recompute hashes only for changed files
• Generate hashes only for production builds (skip in development)
• Use incremental builds in CI/CD pipelines

According to the MDN SRI Implementation Guide, these hash generation methods have been optimized for modern build pipelines, and the overhead is minimal compared to the security benefits.

Our web development services implement performance-optimized build pipelines that include SRI automation without sacrificing build speed.

Best Practices and Common Pitfalls

Implementation Guidelines

• Always include crossorigin for cross-origin resources--without it, browsers may skip integrity verification
• Use SHA-384 or SHA-512 for new implementations (stronger than SHA-256)
• Generate hashes from actual delivered content, not source files (account for CDN transformations)
• Provide multiple hashes if resources might be served in different forms (gzip vs brotli)

Managing Hash Updates

The operational challenge with SRI is managing hash updates when third-party resources change. When a library releases a new version, update your integrity hash to match. Monitor changelogs and update hashes as soon as you've tested compatibility.

Integrate hash updates into your normal dependency update workflow--when you upgrade a library version, also update its integrity hash. Use integrity hashes in health checks to detect increased failures indicating CDN issues or unexpected version changes.

Production Implementation Checklist

Use this checklist when deploying SRI to production:

Pre-deployment:

• Audit all third-party script and stylesheet dependencies
• Generate integrity hashes for each resource using production CDN URLs
• Verify CDN CORS support with integrity attribute
• Test integrity failures in staging environment (simulate hash mismatch)
• Document hash update procedures for dependency upgrades

Configuration:

• Add integrity attribute to all script and link elements
• Include crossorigin="anonymous" for cross-origin resources
• Configure webpack crossOriginLoading for code-split chunks
• Set up hash generation in CI/CD pipeline
• Configure CSP headers to work alongside SRI

Monitoring:

• Set up alerts for integrity verification failures
• Monitor CDN change announcements for dependencies
• Review security advisories for SRI-aware attacks
• Document response procedures for hash mismatch incidents

Common Mistakes to Avoid

According to the MDN SRI Implementation Guide, proper crossorigin configuration is essential for integrity verification to work correctly on cross-origin resources.

Implementing these security measures is a core part of our professional web development services, ensuring your applications are protected against modern supply chain threats.

Sources

1. MDN Web Docs: Subresource Integrity - Core SRI specification and browser behavior documentation
2. OWASP Foundation: Subresource Integrity - Security considerations and risk mitigation
3. MDN: SRI Implementation Guide - Practical code examples and tools
4. Next.js: Content Security Policy Guide - Modern web framework integration patterns
5. SRI Hash Generator - Tool for generating SRI hashes
6. W3C Subresource Integrity Specification - Official standards document