You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My infosec team is requesting that we load the DocSearch JavaScript with the subresource integrity property. I noticed that the Instantsearch.js files support this, as seen in the code snippet here. However the DocSearch code snippet does not offer the same option.
Describe the solution
I realize that I can generate the hash myself, but that’s not a permanent solution if the source file could change without warning.
Can I use this integrity hash and expect the DocSearch JS file not to change?
Investigating this a bit, with how the jsdelivr CDN works, esp. as recommended in the setup instructions, it's impossible to associate SRI with an imprecise version. Per jsdelivr, https://www.jsdelivr.com/using-sri-with-dynamic-files says:
Do NOT use SRI with: version aliasing (version ranges) The purpose of version aliasing is getting automatic updates. This obviously means the code can change any time.
The next question is this: what's the danger of pinning to a particular version of the docsearch library?
One way I'm thinking about working around this for my use case, which is a static site, is to retrieve the latest version of the library from the npm registry API:
Describe the problem
My infosec team is requesting that we load the DocSearch JavaScript with the subresource integrity property. I noticed that the Instantsearch.js files support this, as seen in the code snippet here. However the DocSearch code snippet does not offer the same option.
Describe the solution
I realize that I can generate the hash myself, but that’s not a permanent solution if the source file could change without warning.
Can I use this integrity hash and expect the DocSearch JS file not to change?
The text was updated successfully, but these errors were encountered: