Pular para o conteúdo principal

Strict CSP does not allow unsafe evaluation

What to do when a strict Content Security Policy blocks unsafe-eval and stops Varify from running.

Last updated on 06 de ago. de 20262 min read

What does that mean?

Content Security Policy (CSP) is a security policy that instructs browsers on what types of code are allowed to run on a webpage. The unsafe-eval directive specifically controls whether JavaScript may be dynamically generated and executed at runtime, for example via eval() or the Function() constructor. A strict CSP that does not allow unsafe-eval blocks precisely this type of dynamic code execution in the browser. This applies not only to the website’s own code but also to external tools that reload and execute content at runtime, as is the case with client-side A/B testing tools.

Does the creation and delivery work even without unsafe-eval?

No, technically speaking, creating and delivering experiments isn't possible without unsafe-eval. The reason lies in how the snippet itself works: Experiments aren't statically embedded when the page is deployed, but are retrieved by the snippet as a configuration at runtime and executed in the browser by a JavaScript engine. This is precisely what makes it possible to create or edit an experiment in the dashboard without requiring a new deployment on the customer’s end.

However, a CSP can only allow code that it knows in advance, via a fixed source, a hash, or a nonce. None of these methods work for content that is assembled only after the page has loaded. For the browser to execute this code anyway, it needs eval() or the Function() constructor—precisely what unsafe-eval controls. Since targeting logic and content changes run through the same engine, there is no separate, “safe” execution path that could be enabled solely for simple experiments (text, CSS, images).

Possible Solution

Instead of allowing unsafe-eval site-wide, the CSP can be configured differently for each route. Pages with particularly strict requirements (e.g., login or authentication flows) remain strictly eval-free, while unsafe-eval is only allowed on pages where experiments are actually intended to run.