From bugzilla-daemon@bugs.koha-community.org Fri Mar  6 00:35:18 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 23:35:17 +0000
Message-ID: <bug-38365-70-6TBQ9WHwNu@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="===============0067760798886822039=="

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

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

--- Comment #271 from David Cook <dcook@prosentient.com.au> ---
(In reply to Jonathan Druart from comment #265)
> (In reply to David Cook from comment #258)
> > (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 lo=
ading of a
> > > > > resource (media-src) at data: because it violates the following dir=
ective:
> > > > > =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?
> >=20
> > Nope! I haven't been able to find it. I don't see it anywhere. Does it
> > happen on a particular page?
>=20
> All pages: https://snipboard.io/if28Qu.jpg

Yeah, I don't see that on mine: https://snipboard.io/GSboJW.jpg

media-src is for <audio> and <video> elements, also even that violation messa=
ge
looks weird, although I see other people talking about it online. Do you have
any browser plugins/extensions? I think something in your browser is injecting
audio/video into your pages.

> > > 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
> >=20
> > 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
> >=20
> > (To test this one, you'll want to run `prove
> > t/db_dependent/Koha/Plugins/Valuebuilder_hooks.t`)
>=20
> xt/find-missing-nonce.t is still failing on this file then. Should we
> exclude it?

I think that we should exclude it, since it's good at testing that
Koha::FrameworkPlugin is working correctly at this time.

> > > And those ones when testing the UI:
> > >  * cataloguing/value_builder/* (oops, all cataloguing plugins are broke=
n)
> > > We might need to adjust the xt test and add_csp_nonces.pl to caught tho=
se
> > > files as well.
> >=20
> > 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 plu=
gin
> > scripts".
>=20
> I do see dozens of violations in the console when I edit a biblio:
> https://snipboard.io/X7OYJp.jpg

So those are different violations unrelated to the nonces. Those are due to
inline event handlers, and bug 38407 is for fixing those.=20

If you try the cataloguing plugins for the leader and 008, they're fine. Same
with the item editor. The "tag editor" for 100$a isn't using a cataloguing
plugin. It's using an inline event handler.=20

These inline event handlers need to be moved into <script> elements with nonc=
es
or moved into separate files. But that's what bug 38407 is for.=20

> > 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.
> > When 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
> >=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;
> >=20
> > Yeah I guess so since it won't match. I've written a patch that will cover
> > this (as well as a future where we have other attributes like type for ESM
> > modules or use async or defer).
>=20
> Hum I've revert your patch and tried to see how it broke the tidy but it
> didn't. All good but maybe this is no longer needed. Will keep in mind if
> some tidy errors appear in the next weeks.

I was wondering that too. That bit of tidying is just collapsing multiple new
lines into a single new line, so I'm not sure it's that helpful?

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

--===============0067760798886822039==--