From bugzilla-daemon@bugs.koha-community.org Thu Mar  5 05:05:44 2026
From: bugzilla-daemon@bugs.koha-community.org
To: koha-bugs@lists.koha-community.org
Subject: [Koha-bugs] [Bug 38365] Add Content-Security-Policy HTTP header to
 HTML responses
Date: Thu, 05 Mar 2026 04:05:44 +0000
Message-ID: <bug-38365-70-Yjrec87a6f@https.bugs.koha-community.org/bugzilla3/>
In-Reply-To: <bug-38365-70@https.bugs.koha-community.org/bugzilla3/>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5332286908870742478=="

--===============5332286908870742478==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3D38365

--- Comment #258 from David Cook <dcook@prosentient.com.au> ---
(In reply to Jonathan Druart from comment #253)
> > > 7. When enabled, I see an error in the browser's console:
> > > Content-Security-Policy: The page=E2=80=99s settings blocked the loadin=
g of a
> > > resource (media-src) at data: because it violates the following directi=
ve:
> > > =E2=80=9Cdefault-src 'self'=E2=80=9D
> >=20
> > That's interesting. I'd like to hear more about this one. Were there
> > additional details? I wonder if it had to do with audio when doing a
> > checkout or something?
>=20
> No idea! There is nothing else! Don't you see it?

Nope! I haven't been able to find it. I don't see it anywhere. Does it happen
on a particular page?

> Ok, however I found more:
> Caught by the xt tests (and now by add_csp_nonces.pl as well)
>  * t/lib/plugins/Koha/Plugin/TestValuebuilder/test_valuebuilder_popup.tt

So this is an interesting one. I will upload a patch for this one, but it's
going to work differently to what you might expect. I'll explain more in my
response to your comment about cataloguing plugins.=20

(To test this one, you'll want to run `prove
t/db_dependent/Koha/Plugins/Valuebuilder_hooks.t`)

> And those ones when testing the UI:
>  * cataloguing/value_builder/* (oops, all cataloguing plugins are broken)
> We might need to adjust the xt test and add_csp_nonces.pl to caught those
> files as well.

So these aren't actually broken. When I was first working on the patches, I
thought they would be, but the script tags are actually already re-written by
Koha/FrameworkPlugin.pm, so it adds the nonce to them. If you try out the
cataloguing plugins, they should all work without any violation reports. See
the patch labelled "Bug 38365: Fix nonce caching and add to framework plugin
scripts".

I think an argument could be made for fixing them a different way... and you
just reminded me of why I used an ENV variable initially. It was for this. Wh=
en
the plugins get launched the CGI context gets re-set which is why I lost the
cached values, but the ENV variable would persist and the package level
variable are fine.=20

> Also wondering if this one won't require adjustment:
> misc/devel/tidy.pl:172             $content =3D~ s#\n*(
> *)<script>\n*#\n$1<script>\n#g;

Yeah I guess so since it won't match. I've written a patch that will cover th=
is
(as well as a future where we have other attributes like type for ESM modules
or use async or defer).

> > > 10. Vue apps have styling issues:
> > > Content-Security-Policy: The page=E2=80=99s settings blocked an inline =
style
> > > (style-src-elem) from being applied because it violates the following
> > > directive: =E2=80=9Cstyle-src 'self' 'nonce-UrNLygw_Cc1zaPU2WH0qVk'=E2=
=80=9D. Consider using
> > > a hash ('sha256-t4I2teZN5ZH+VM+XOiWlaPbsjQHe+k9d6viXPpKpNWA=3D', requir=
es
> > > 'unsafe-hashes' for style attributes) or a nonce.
> > > It's coming from insertBySelector.js and styleTagTransform.js
> >=20
> > I have been wondering if the Vue apps would have trouble.=20
> >=20
> > According to https://webpack.js.org/loaders/style-loader/#nonce,
> > style-loader isn't recommended for production. Note the security warning =
on
> > https://www.npmjs.com/package/style-loader as well. How does style-loader
> > get used in Vue currently?
>=20
> Looks like it is used to load all the inline style tags.
>=20
> Todo - Vue apps are broken.
> Todo - Adjust xt test to parse .vue files(?)

Since style-loader isn't recommended for prod use, I think we look at replaci=
ng
that. It looks like "mini-css-extract-plugin" is typically what's used which
will put the CSS into a separate file.

Note that nothing is broken per se. We're not turning on CSP by default, and
you can always override the default CSP to allow inline styles if you want. So
we have time to work out some of these changes while still forging ahead.

I see what you mean though. If I turn on ERM and go to
http://localhost:8081/cgi-bin/koha/erm/home I see a lot of inline style
violations.=20

Alternatively, I think that style-loader might have support for
__webpack_nonce__ . I need to have a very late lunch but I'll check that out
too...

> Ok, will try again later, when the other points will be resolved.

If you check out my latest test plan (marked important) it should give you all
the steps to get reports in the logs.=20

> > > Side note: This will heavily conflict with bug 41324... Easy to fix, but
> > > boring.
> >=20
> > I think it should be OK? We can toss the "Bug 38365: Add CSP nonces to all
> > inline script and style tags" patch and re-generate to fix the merge
> > conflict.
>=20
> If this one passes first it will be messy, but I am inclined to do the dirty
> job.

Ah I think that I understand now. Happy to give you a hand with that too.

--=20
You are receiving this mail because:
You are watching all bug changes.

--===============5332286908870742478==--