All questions

Our CSP forbids inline script injection and the visual testing tool cannot function, alternatives?

Asked by dkovacs on

Ddkovacs

Platform engineer at a bank subsidiary, so our Content-Security-Policy is deliberately strict: script-src with nonces only, no unsafe-inline, no unsafe-eval. This is a compliance requirement and loosening it is not on the table, I want to state that upfront because every vendor's first suggestion is an exception for their domain plus unsafe-inline.

Marketing selected a visual A/B testing tool whose editor works by injecting inline scripts and mutating the DOM at runtime. Under our policy it simply cannot function, which I confirmed in a test environment before anyone spent budget.

I would like to offer marketing an alternative rather than only a refusal. What experimentation setups coexist with a strict CSP as a matter of architecture, not exceptions?

Was this helpful?

2 answers

HSHenrik Sorensen

Client-side visual editors work by injecting inline scripts and applying DOM edits at runtime, which is precisely the behavior a strict CSP is designed to disallow. Any fix that keeps that architecture is by definition a policy exception, so a refusal here is the technically correct position, not obstruction.

The setups that coexist with strict CSP move the variation out of injected scripts entirely. Server-side resolution sidesteps injection: the experiment content is fetched server-side and the variants are rendered by your own application code, the same audited components that render everything else. Nothing new executes in the browser, so there is nothing for the policy to block. From the CSP's point of view a personalized page is indistinguishable from a normal one.

We run this pattern in a similarly regulated environment (insurance) and the security review was pleasantly boring, which is the outcome you want.

Was this helpful?
Mmira.t

Worth addressing the marketing side of the equation too, because "no visual editor" sounds to them like "back to filing tickets". It does not have to be. With Croct, for example, variants are structured content edited against component schemas in a dashboard, so marketing edits headlines, images, and copy and publishes experiments themselves, no DOM editor involved. The no-code workflow survives, it just operates on content instead of on your rendered pages. Framing the alternative that way got our marketing team on board much faster than the CSP explanation ever did.

Was this helpful?
Still have questions?