J!4: Content Security Policy

[sozzled]

It may (or may not) be a big deal if people are aware (or not aware) of the new Content Security Policy component built into J! 4.

There isn't much documentation about this feature apart from:

1. https://docs.joomla.org/Help4.x:Content ... Options/en
2. https://docs.joomla.org/Help4.x:Content ... Reports/en

Apart from that—the lack of documentation or a link to the video presentation (which you can find if you look at this magazine article)—the feature seems to have a few problems that are preventing the release of J! 4.0 RC. It begs the question about the benefits of the feature for most of us and its inclusion in J! 4.0. It may be better to defer its implementation until J! 4.1, say, so that J! 4.0 could be released sooner. It probably depends on who are requiring this as early as day one of J! 4.0 and who are driving the urgency.

The problems with the Content Security Policy component are only one example of issues holding up the release of J! 4.0 RC. They're not the biggest problems by any means but they exist in this component. Problems/"release blockers" also exist in several other new features intended for J! 4.0.

Some of these new features for J! 4.0, while they were designed several years ago with the best of intentions, are holding back the release of J! 4.0 (and, of course, J! 3.10) and, in the meantime, we're limping along slowly with J! 3.x that is showing its age. I don't think anyone wants J! 3.10 and J! 4.0 to be rushed but I think that the development team should have a meeting to consider what what's deliverable within the short-term and what may have to be—perhaps "unfortunately"—deferred until later ... unless the non-availability of specific features is so tightly coupled into the whole J! 4.0 product that it's impossible to isolate those features from J! 4.0.

Just saying, that's all.

[ceford]

There is also this: https://docs.joomla.org/J4.x:Http_Header_Management which contains some links to articles explaining CSP. The Notes for Extension Developers are interesting. Amongst other things is the need to avoid onClick (etc) and in-line css.

There are also links to articles on CSP in the HTTP Headers plugin (shortly to be replaced by links to articles more likely to be maintained long term). It is the case that com_csp needs work and there has been a discussion about delaying it to 4.1. It is scheduled to ship with 4.0 but is not enabled by default. I spent a couple of days experimenting with it. I learned a lot but probably not enough!

[sozzled]

Thanks, @ceford, for the important extra information—that wasn't immediately obvious to me—and for sharing your thoughts about the impact that the unavailability of a working com_csp (and allied software) may have on the plans to release J! 4.0 in the near term.

Reading through the documentation about HTTP Header Management (and putting aside that the feature is optional and there's no requirement to enable the facility unless some website owners see a benefit in using it), it may be a bigger deal for some people than it is for others. Further, the impact may be felt on this forum (and other online technical forums) when we read

... the big security advantage concerning Content Security Policy jumps in when we can use the Header to block all inline JavaScript and inline CSS affecting for example JavaScript event handlers via HTML attributes. So with this browser protection enabled we will block inline JavaScript and inline CSS usage also for your extensions. That protection is not enabled by default but can be enabled by your users.

The impact on the forum will probably be felt when people say, "my such-and-such doesn't work" (where such-and-such is the website owner's own use of inline JS/CSS or the use of extensions that haven't been worked in ways to make them compatible with J! 4. This could be a "gotcha".

I understand the appeal that some additional security-related feature will have for many website owners (and that's a good thing) but unless website owners really understand the ins-and-outs of what these additional security functions do and the possible side-effects in using them, this could be a long-term running sore.

Further along in the documentation we see that, by enabling a "strict Content Security Policy" (and who wouldn't want a policy that keeps everything nice and clean from a security viewpoint, eh?),

... the following features will be blocked:

• the execution of JavaScript via the HTML event handlers (onXXX handlers like onClick and similar)
• the execution of in-page JavaScript not passed to the page via the Document API
• the execution of JavaScript code injected into DOM APIs such as eval()
• the usage of inline in-page CSS not passed to the page via the Document API
• the usage of inline CSS using the HTML style attribute

Hmmm ...

So the "notes" for extension developers, whose products may be jeopardised by these actions and whose reputations may be rattled when their customers write to them with "Your product is broken" requests for support, may be a little ... um ... "complicated", putting it mildly. I don't understand what it means for me, as a website owner or as someone tempted to create J! extensions, what to do or how to navigate my way through the likely problems that will occur by diving into the content security policy feature.

Not saying it's not a good idea but it may be better to hold off on this for the present, release J! 4.0 (without it), let people learn to swim with everything else that comes with J! 4.0, and ensure there are plenty of swimming coaches available to teach novice J! 4 users to become advanced "swimmers".

While a lot of this may sound like "techno-babble" to novices, I understand a good deal about DOMs, and APIs and inline JS and CSS, and HTML event handlers because I've been using these things for the past 15+ years in my webcraft. And while there may be purists among us who eschew the unfettered, unconstrained use of onClick or eval() usages and who would advocate that these things shouldn't be allowed in the ways that people use them, sometimes it's easier to "just do it" that way. Yes, I am not someone who normally uses inline "anything" but sometimes ... well, y'know ...

And just because I may use inline "somethings" shouldn't be an opportunity for hard-line purists to condemn me for it.

While the Content Security Policy feature will probably be included with J! 4.0 (although not enabled by default), and it will further add to delaying the release of J!4.0—because we don't know otherwise—it sounds like forbidden fruit to me.

Just saying, it's a bit too much for some of us to absorb in one hit.

[sozzled]

For all intents and purposes, this issue is now dead. See viewtopic.php?f=803&t=985728&p=3630024#p3630024