Instantsearch.js: Avoid using eval

[zeke]

Is your feature request related to a problem? Please describe 🙏

I am adding a Content Security Policy to a new website that's (happily) using instantsearch.js. I noticed that in order for search to keep working with our CSP, we have to make some exceptions:

{
  directives: {
    defaultSrc: ["'none'"],
    connectSrc: [
      '*.algolia.net',
      '*.algolianet.com'
    ],
    scriptSrc: [
      "'self'",
      "'unsafe-eval'" // exception for Algolia instantsearch.js
    ],
    styleSrc: [
      "'self'",
      "'unsafe-inline'"// exception for Algolia instantsearch.js
    ]
  }
}

Describe the solution you'd like 🤔

I would like to disallow unsafe-eval for scripts and unsafe-inline for styles in my CSP and continue using instantsearch.js

Apologies, but I have not yet looked into the specific code in this library that using eval or similar. Just opening this as a tracking issue and to hopefully get a conversation started. Thanks!

[Haroenv]

Related issue: https://github.com/algolia/instantsearch.js/issues/2868, it seems to be Webpack's fault actually. I wonder how this is still the case now that we are using rollup. Are you using the latest version @zeke ?

[zeke]

$ npm ls instantsearch.js
[email protected] /Users/z/git/github/help-docs
└── [email protected] 

Looks like we are behind a major version. I will update to 3.1.0 and report back.

[Haroenv]

Migration guide is available here: https://www.algolia.com/doc/guides/building-search-ui/upgrade-guides/js/?language=js#upgrade-from-v2-to-v3

[Haroenv]

I've looked into it, and eval is definitely gone in 3.0.0+, however the new Function mentioned in #2868 will still be there, for Hogan templates, which accept arbitrary JS interpolation. I don't think there's a way to avoid that. Maybe something is possible with template strings, but it should be investigated further. Preferably some way which doesn't use Hogan anymore, although I haven't seen many libraries which are: small, easy templating, safe.

[zeke]

Thanks for looking into it, @Haroenv

Preferably some way which doesn't use Hogan anymore, although I haven't seen many libraries which are: small, easy templating, safe.

Maybe mustache?

[Haroenv]

Yes. We discussed this, and will find a solution (not now, in a while), where the templating would be an “open-ended” API instead of just a string. Mustache is better than Hogan as a replacement; but it’s a few KB bigger, and we don’t want to switch for that now. Have you been able to change your CSP with the latest version?

[zeke]

Have you been able to change your CSP with the latest version?

Haven't tried it yet (not a top priority) but I will report back soon.

[zeke]

We upgraded to instantsearch.js v3. Works like a charm! Unfortunately, as you predicted, it still requires the same style-src and unsafe-eval allowances. Here's what I see when I try to disable them in the CSP:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-GPZkwLiIhsNMfLMOGEUTYsWaCrqUZGzs19r89uce84c='), or a nonce ('nonce-...') is required to enable inline execution.

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' data: *.google-analytics.com".

[Haroenv]

Thanks for trying it out. Unfortunately I think removing those will be a breaking change, so not something we will be able to get to for the coming months. For the styling; you can add the hash as it suggested; for unsafe-eval, this is likely due to the templating. I don't think it's completely trivial removing or replacing that one though. It's something that will take us at least a few months to get to. Is that okay? For now I'll close this issue, since we found out the things we have are still the same violations as described in #2868

[zeke]

Sounds good @Haroenv, thanks for following up.