Feature Request: adding `insecureUnsafeInline` property to CSP middleware

[Hajime-san]

Currently, nonce-based CSP middleware trims unsafe-inline value specified by the user.

https://github.com/denoland/fresh/blob/39b5f06f8a7d7fa02dd2e2950f2291d04ef9fea7/packages/fresh/src/middlewares/csp.ts#L126-L128

This is ideal from a security standpoint. However, in real-world workloads, it may be necessary to inline style-src or use unsafe-inline for script-src as a fallback for older browsers.

For example, major sites like YouTube also specify unsafe-inline.

% curl -sI https://www.youtube.com/ | grep -i "content-security-policy" | tr ';' '\n'
content-security-policy: require-trusted-types-for 'script'
content-security-policy: base-uri 'self'
object-src 'none'
script-src 'nonce-DlUyhkt87IXfH56peGtAYQ' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval'
report-uri https://csp.withgoogle.com/csp/youtube_main/strict

Therefore, I propose adding a new property called insecureUnsafeInline to the CSP middleware.
The user can explicitly prevent the aforementioned trimming of unsafe-inline value by setting this to true.

[bartlomieju]

Thanks for filing this — the use case is real and the current behavior does break the strict-CSP fallback pattern that web.dev (and YouTube, as you showed) recommend. Modern browsers ignore 'unsafe-inline' once 'nonce-…' or 'strict-dynamic' is present, so keeping it as a fallback for older browsers is the secure pattern, not an unsafe one.

That said, before adding the flag I'd like to question the framing a bit:

1. Naming. Calling it insecureUnsafeInline will steer users away from doing the right thing, since the recommended strict-CSP setup actually wants that fallback. Something like keepUnsafeInline or preserveUnsafeInlineFallback would read better.

2. Granularity. A global boolean is coarse — in practice you often want the fallback on script-src (for old browsers) but not on style-src (where nonces work cleanly). A per-directive option (e.g. unsafeInlineFallback: [\"script-src\"]) would match real configs better.

3. Do we even need a flag? I'd argue the root cause is that the current code uses replaceAll(\"'unsafe-inline'\", \"'nonce-…'\") — replacing rather than augmenting. If we change it to simply append the nonce alongside whatever the user wrote, the FR goes away: users who want the fallback keep 'unsafe-inline' in their config; users who don't, omit it. That respects user intent in both directions without a new API surface.

Would you be open to a PR along those lines (drop the stripping, append instead) instead of adding the flag? Happy to take a stab at it if so.

[Hajime-san]

@bartlomieju

Would you be open to a PR along those lines (drop the stripping, append instead) instead of adding the flag? Happy to take a stab at it if so.

Yep, I think it's better. However, it is important to keep that in mind since the behavior described in the documentation change.

https://fresh.deno.dev/docs/plugins/csp#nonce-based-csp

The CSP header replaces 'unsafe-inline' with 'nonce-{value}' in script-src, style-src, default-src, script-src-elem, style-src-elem, and style-src-attr directives.