Onpane

Subresource Integrity (SRI)

When you add a third-party script to your website, you trust that the file your visitors download is exactly the file you intended. But what if someone tampers with it between the server and the browser? Subresource Integrity (SRI) solves this problem by letting browsers verify that a script has not been modified.

What is SRI?

SRI is a browser security feature defined by the W3C. When you include a script tag with an integrity attribute, the browser does the following:

  1. Downloads the script file as usual
  2. Computes a cryptographic hash (like a fingerprint) of the downloaded file
  3. Compares that hash to the expected value in the integrity attribute
  4. If the hashes match, the script runs normally. If they do not match, the browser blocks execution entirely.

Think of it like a tamper-evident seal on a package. You cannot prevent someone from opening the package in transit, but you can tell immediately if they did.

Why It Matters

Without SRI, several attack scenarios can lead to your visitors running malicious code:

  • CDN compromise — an attacker gains access to the CDN hosting a script and replaces the file with a malicious version
  • Man-in-the-middle attacks — on networks without strict HTTPS enforcement, an intermediary could modify the script in transit
  • Supply chain tampering — a compromised build pipeline or hosting provider could inject unwanted code

With SRI, even if any of these attacks succeed in modifying the file, the browser will refuse to execute it. The integrity check happens entirely in the browser, independent of how the file was delivered.

How Onpane Uses SRI

SRI is available for customers who self-host the Onpane widget. When you download the widget file and serve it from your own infrastructure, you control exactly when the file changes, making SRI a practical and reliable way to verify script integrity.

The standard hosted embed code (the script tag from your project settings) does not use SRI. This is by design: the hosted widget auto-updates with each Onpane release, and every update changes the file's hash. If the embed code included a fixed SRI hash, the browser would block the widget after the next release, breaking your site until you manually updated the hash.

Self-hosted users do not have this problem. You download a specific version of the widget file, and it stays unchanged on your server until you decide to update it. This makes SRI a natural fit for self-hosted deployments.

Self-Hosted SRI Setup

If you download and self-host the Onpane widget, you can still use SRI. The SRI hash for onpane-widget.js is published in the widget manifest:

  1. Fetch the manifest at https://onpane.com/widget/manifest.json
  2. Copy the sri value for onpane-widget.js
  3. Add the integrity and crossorigin="anonymous" attributes to your script tag
HTML
<script
  src="/js/onpane-widget.js"
  integrity="sha384-HASH_FROM_MANIFEST"
  crossorigin="anonymous"
  data-key="YOUR_API_KEY"
  data-api="https://onpane.com"
></script>

Important: whenever you update the widget file on your server, you must also update the integrity hash. An outdated hash will cause the browser to block the updated script.

manifest.json Reference

The widget manifest is publicly accessible at /widget/manifest.json. It contains metadata for each published widget file:

JSON
{
  "generated": "2026-03-17T12:00:00.000Z",
  "files": {
    "onpane-widget.js": {
      "sri": "sha384-abc123...the-full-hash",
      "size": 12345
    }
  }
}

Self-hosted users should use the hash for onpane-widget.js, which is the standalone widget bundle available for download.

  • generated — ISO 8601 timestamp of when the manifest was created
  • files — object keyed by filename, each containing:
    • sri — the SHA-384 hash prefixed with sha384-, ready to use in the integrity attribute
    • size — file size in bytes

Best Practices

  • Always pair integrity with crossorigin="anonymous" — SRI requires CORS to function correctly for cross-origin scripts
  • Update the hash whenever you update the script file — mismatched hashes will block execution
  • Use SHA-384 — it is the hash algorithm recommended by the W3C SRI specification and provides a strong balance of security and performance
  • Test after updating — verify your page loads correctly with the new hash before deploying to production