KrakenJS Helmet CSP script-src directive default value

Short answer

No — KrakenJS should not bake in a default script-src 'self' strict-dynamic. A strict-dynamic default only works when every entry-point script carries a nonce or hash, and KrakenJS has no templating pipeline that guarantees that. Shipping it as a default would break inline scripts, event handlers, and third-party widgets on first deploy. The right default is to leave script-src explicit, but ship a documented, opt-in policy pattern with a nonce-based fallback for older browsers.

What is confirmed vs. likely

Confirmed behavior of the pieces: strict-dynamic is ignored by browsers that don't support it (IE11, Safari before 14, older mobile browsers); those browsers fall back to the other sources listed in script-src. Modern browsers (Chrome 52+, Firefox 52+, Safari 14+) honor it and ignore host allowlists like 'self' in favor of trust propagated from a nonced script.

Likely, but verify in your install: KrakenJS has been effectively unmaintained since ~2018, and its bundled Helmet version predates Helmet v4's CSP-by-default behavior. Depending on the pinned Helmet version, your app may emit no CSP at all or a minimal one. Check before assuming anything:

npm list helmet\ncurl -sI https://your-app.example/ | grep -i content-security-policy

Recommended pattern (opt-in, not default)

The standard compatible policy pairs a nonce with strict-dynamic:

script-src 'self' 'nonce-{per-request-random}' 'strict-dynamic'

Modern browsers use the nonce on the bootstrap script and strict-dynamic to trust scripts it loads. Legacy browsers ignore strict-dynamic and execute only scripts carrying the valid nonce. 'self' acts as the legacy fallback for externally hosted first-party scripts; in strict-dynamic browsers it is ignored, so it costs nothing to include.

Handling the constraints

• Inline scripts: Without a nonce-deployment step in your templates, any default that omits 'unsafe-inline' breaks them immediately. This is the core reason it can't be a framework default.
• Third-party widgets: Analytics, chat, and ad scripts load further scripts dynamically — exactly what strict-dynamic is for — but only if their loader tag is nonced. A universal default can't know these domains, which is another argument against baking one in.
• Report noise: Roll out in report-only mode first:

  helmet.contentSecurityPolicy({\n  reportOnly: true,\n  directives: { scriptSrc: [\"'self'\", \"'nonce-...'\", \"'strict-dynamic'\"] }\n})

  Collect reports for one to two weeks, fix nonce gaps, then enforce. Ensure your report endpoint can handle volume or sample reports.

Bottom line

Given KrakenJS's maintenance status, a baked-in default would have to work unattended for years across unknown applications — strict-dynamic fails that test. Provide the nonce + 'self' + strict-dynamic pattern as documented configuration, with report-only as the migration path. If your Helmet version turns out to be v3-era (no default CSP), the first step is simply enabling CSP explicitly at all.