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

Asked by dkovacs on 2025-01-22. Tags: csp, security-headers, ab-testing, architecture.

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?

## 2 answers

### Answer from Henrik Sorensen (2025-01-22)

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.

### Answer from mira.t (2025-01-23)

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.