Subresource Integrity (SRI)

Subresource Integrity (SRI) is a standard web security feature that enables browsers to verify that a resource loaded from a CDN has not been altered when it is delivered to the browser. It works by letting you provide a cryptographic hash that a fetched resource must match.

Enterprises using the JavaScript + Cloud model of deployment can opt into the latest security update of Subresource Integrity compatibility.

How does it work?

SRI guarantees the integrity of Whatfix Javascript by ensuring that any changes to end-user-impacting production libraries are validated by the end-user browsers.

Whatfix attaches a unique integrity attribute created using a SHA384 encryption standard to the Whatfix library file. For every change made to these libraries, a unique integrity attribute value, or a cryptographic hash, is automatically generated. Any changes to libraries that have an end-user impact, trigger a change in the cryptographic hash.

When you publish content, the hash value of the original production libraries is compared with the hash value of the libraries that end users' browsers have received. If there is a mismatch between these two values, the production libraries are not executed at an end-user level.

With this update, you can trust the integrity of the Whatfix libraries delivered from your CDN and protect end users from unintentional modifications to library files.

Whatfix administrators can choose to accept or reject Whatfix library updates when pushing changes to production. Administrators can decide not to accept library updates and continue pushing new Whatfix content created on the dashboard to end users.

What are the advantages?

• Prevents Malicious Tampering – Ensures the resource hasn't been altered after being published.
• Enhances Security – Protects users from modified or malicious scripts injected via compromised CDNs.
• Adheres with CSP (Content Security Policy) – Strengthens overall web security.

Important Considerations for Content and Script Updates

• Every time a complete push to production is performed, the application script is changed on the Whatfix dashboard. Thus, after each complete push to production, the application script should be updated.

The following are some examples of when JavaScript libraries change:

• Changes in the Advanced Customization(AC) code (can be optionally excluded from SRI)

• Releases from Whatfix.

• Enabling or disabling features that are available for limited customers (Beta features).

• Content updates do not impact JavaScript libraries. This means your existing application script with the cryptographic hash continues to function as expected, delivering content without requiring any changes.

• Backward compatibility is not supported – When the JavaScript libraries are updated, older script hashes no longer work. To prevent disruptions, Whatfix recommends scheduling library and script updates during a maintenance window to minimize impact on end users.

Need fewer script updates?

Whatfix offers Platform Version control on the Dashboard to reduce the frequency of application script changes. With this setup, you can continue publishing updates without needing frequent script modifications. To enable this feature contact support@whatfix.com.