Very nice

This PR now implements the key part of the prozess the com_csp Component including the reporting endpoint. The other features are going to be added step by step.

Looking at the code, i see that the part to allow the "Published" the blocked elements is not done yet, right ?

Missing string?

When the CSP is not enabled in the httpheaders plugin and/or the plugin is disabled then there should be a notification in the CSP component. Something similar to the message in com_finder and com_redirect

You need to add an entry for JHELP_COMPONENTS_CSP_REPORTS in administrator\language\en-GB\en-GB.ini

@zero-24

all _1 strings are for singular so should just be option

You only changed the one i commented one - sorry if I wasnt clear

Missing string?

Looks like i have just not pushed the needed string yesterday. Sorry.

You need to add an entry for JHELP_COMPONENTS_CSP_REPORTS in administrator\language\en-GB\en-GB.ini

Done.

Looking at the code, i see that the part to allow the "Published" the blocked elements is not done yet, right ?

Just to be sure i guess you mean the publish button? We are not implementing that our self we use the core / lib function for that :) So no need for component code here. Just try it is is working :)
Or do you mean something else?

When the CSP is not enabled in the httpheaders plugin and/or the plugin is disabled then there should be a notification in the CSP component. Something similar to the message in com_finder and com_redirect

Done.

You only changed the one i commented one - sorry if I wasnt clear

Should be fixed now too thanks!

needs to be added to the administrator\components\com_menus\presets\joomla.xml and modern.xml

needs to be added to the administrator\components\com_menus\presets\joomla.xml and modern.xml

Where there? Isn't this component part of the component container?

My mistake sorry

My mistake sorry

np. thanks for checking,

I have tested this item ✅ successfully on 1253847

implemented the requested changes cc @laoneo @Quy

Missing language string.

I am not familiar CSP so I don't know why no saved entries in the back end.

Missing language string.

Should be fixed with the latest commits. Thanks!

Under Table Options > Select Status, there is an option to filter on Archived. I assume this should not be an option.

Under Table Options > Select Status, there is an option to filter on Archived. I assume this should not be an option.

Technically this is a possible status even when we have no UI Button to set it.

Fixed the other problems.

I have tested this item 🔴 unsuccessfully on 1253847

500: Class Joomla\CMS\Table\Csp not found

xampp, win 10
PHP 7.1.8
MySQLi 5.5.5-10.1.26-MariaDB
Caching Disabled
Gzip Disabled

@ReLater please test after the latest changes. That should fix your error.

I don't get an error page, however, a 500 in the Network tab.

I have tested this item ✅ successfully on 1253847

I don't know if this find makes my last "successfully" an "unsuccessfully". I could live with it for the moment.

I don't get an error page, however, a 500 in the Network tab.

@Quy Just to clarify. The right part in my image concerning 500 error page is from Network tab, too. Don't know in English how the tabulator I selected is named there: "Antwort".

I don't have reported entries in the backend under Content Security Policy. Do you?

I don't have reported entries in the backend under Content Security Policy. Do you?

All done like described in the instructions and all fine. I additionally installed the Blog Sample Datas (I don't think that's necessary) and have set error reporting to "Maximum".

Maybe: Client settings of the plugin must be "Site"! I had no reports in the beginning because the radio buttons have too large clickable areas on the right side and I switched the setting accidentally to "Administrator" before saving.

I typed the URL wrong. It is working now. Thanks!

@ReLater I have just added the language strings.

I have tested this item ✅ successfully on 1253847

After replacing administrator/language/en-GB/en-GB.com_csp.ini with newly committed one.

I have tested this item 🔴 unsuccessfully on 1253847

After disabling of plugin HTTPHeaders System Plugin:

Notice: Trying to get property of non-object in C:\xampp718\htdocs\joomla4-cspj4\administrator\components\com_csp\Helper\ReporterHelper.php on line 31

Notice: Trying to get property of non-object in C:\xampp718\htdocs\joomla4-cspj4\administrator\components\com_csp\Helper\ReporterHelper.php on line 31

Thanks I have just reverted the PluginHelper Part. That should fix the problem.

I have tested this item ✅ successfully on 1253847

The font size of URL and Blocked Element columns are smaller than the other columns. OK?

1 option published. Why is it option and not item?

1 option published. Why is it option and not item?

hmm I would like to ask @brianteeman on that. Technical this is going to be the value of the directive but for now this is just a collected uri given that only enabled entries get added to the csp header. I don't know what is the best option here.

The font size of URL and Blocked Element columns are smaller than the other columns. OK?

Well the two columns with smaller font size are document_uri and blocked_uri given that they can be very long. I'm fine to remove the class but this is more a cosmetic change. Given that the backed is not final yet I would like to keep it as it is.

I think we can move forward here so we can start Implementing the integration of com_csp & plg_system_httpheaders and talking about the cosmetic things when the backend template is ready.

I have tested this item ✅ successfully on 1253847

Lets merge it and decide on the right terminology later.

RTC

It is your turn now @wilsonge :P Thanks for all the feedback I got here. Very highly appreciated 👍

@zero-24 i am checking those strings for you now

@zero-24 see brianteeman/joomla-cms@503094e

Thanks @brianteeman I have just responded to the suggestions all other changes looks good to me Thanks! 👍

This comment is not going to be popular but first some background. I have met Scott Helme a few times and heard him speak and I absolutely understand what CSP and http headers is all about. But i am not a typical user. CSP etc is a very complex issue that takes skill and knowledge to implement.I am 100% convinced that the Joomla target does not have that experience and that having com_csp is just opening a minefield of issues and making joomla appear to be too complicated.

Ask yourself this question - how many of you had even heard of CSP and http security headers before this PR. I bet very few and those of us reading this are more skilled than the typical user.

So what is the solution to that? If it was just a plugin then it would be like the p3p plugin - you either know what it is and use it or you simply ignore it. But the component raises its profile and introduces a very complex (and potentially dangerous) feature front and center.

In conclusion I am NOT in favour of this component being in core. At best it should be a core supported addon.

I agree that the majority of people will not recognise CSP aside from those who have more knowledge than normal. But I'm going to choose to overrule that based on three factors.

1. Firstly we're making a conscious effort to overcome the community reputation we hold in some areas about us not being as security conscious as other CMS'. This component shows us putting security first
2. I expect the default parameters here to change quite a bit before stable. I expect by default we will whitelist google fonts, google analytics + adwords, and some of the major CDNs as well as local CSS (without a nonce). It's not necessarily the most secure set of settings - but it should allow the majority of sites to work give or take out of the box without major reconfiguration.
3. The design rework is going to give us a separated dashboard and set of components. There is now a more conscious separation between administration components and day to day content components with the split of dashboards. Not all administrators are actually going to be totally aware of this extension.

While I agree with Brian's concerns, there's a part of me that right now is thinking "just go for it" and let's have it as a feature through beta phase. Worst case scenario, some of the concerns about the usability and use in general are proved to be true and we move these tools to standalone packages, but at that point hopefully they're also in better shape as it relates to UX and workflow if there are issues needing addressed.

Ok just to clear some points.

re @brianteeman

CSP etc is a very complex issue that takes skill and knowledge to implement.

Yes. It takes a bit of understanding but providing a tool that help with the Implemention is the intend of this PR and the following PR's also raising awarenes about that Technologie.

I am 100% convinced that the Joomla target does not have that experience and that having com_csp is just opening a minefield of issues and making joomla appear to be too complicated.

Where does that 100% convince come from?
This feature was never intended for the people that don't know what html is. It is also not intended for that users who think the JSST (Or Joomla at all) has access to the admin PW's..

This feature like multilanguage, redirect, overrides is implemented for the people that know what they are doing or at least read a bit of documentation (that is going to be published until 4.0 stable).

I think we all know that this does not make the whole process super easy for anyone like just one click but at least for the users who care about security or want to improve it at all they get a tool to do this kind of easy with the backend tooling that help with that.

Ask yourself this question - how many of you had even heard of CSP and http security headers before this PR. I bet very few and those of us reading this are more skilled than the typical user.

Maybe but by that argument any new feature needs to be blocked as no one can have heard about it ;) Raising awareness is one more argument to implement it ;)

So what is the solution to that? If it was just a plugin then it would be like the p3p plugin - you either know what it is and use it or you simply ignore it. But the component raises its profile and introduces a very complex (and potentially dangerous) feature front and center.

On what basis does the very complex and potentially dangerous definitions come from?

Sure you can break your site if you do it wrong. But you can also unpublish all auth plugins or edit the template files and noone ever told in the PR it is to complex or potentially dangerous because if you don't understand it or you will not understand it you don't use it :)

At best it should be a core supported addon.

You know what happen with core supported addons in the past and you know why we stopped creating core supported addons. Also this would not allow the site owners to get know about this possible solution for the problems they are facing.

re @wilsonge

Firstly we're making a conscious effort to overcome the community reputation we hold in some areas about us not being as security conscious as other CMS'. This component shows us putting security first

Full agree.

I expect the default parameters here to change quite a bit before stable. I expect by default we will whitelist google fonts, google analytics + adwords, and some of the major CDNs as well as local CSS (without a nonce). It's not necessarily the most secure set of settings - but it should allow the majority of sites to work give or take out of the box without major reconfiguration.

I'm not in favour adding default whitelists at all. With this tooling it is like recording a excel makro. You enable reporting all reports come in you enable the suggested rules done. Nothing complicated.
Also CSP is not going to be enabled by default. Everyone should make an informed decision about enableling that feature.

The design rework is going to give us a separated dashboard and set of components. There is now a more conscious separation between administration components and day to day content components with the split of dashboards. Not all administrators are actually going to be totally aware of this extension.

I guess this is about the new backend template? If so this is out of scope for this PR but I'm happy to help implement it for com_csp in a later PR.

This post explains what I meant about it being dangerous.
https://www.tunetheweb.com/blog/dangerous-web-security-features/

There is a massive difference between reading some docs about setting up redirects and successfully implementing CSP. There is no comparison to the level of skill and knowledge required.

I understand the concerns but after reading the linked article I've learned "Don't use it if you don't know what you are doing." and "Some outdated (unsecure?) browsers may not understand CSP."

On the other hand users can activate "Force SSL" in Joomla and as I know from forums and jobs bring freequently down their sites completely or partially (unsecure content).
Others check "Activate HSTS" in their SSL provider settings because it's "more performant and more secure" and don't think about the risks concerning cache in user browsers that possibly may occur.

Security settings (= blocking this or that) combined with half knowledge will always be double-edged swords.

From my point of view com_csp is a helpful extension and as far as I can see at the moment a well configurable extension where I haven't got anything against seeing it in core.

Maybe we should integrate a consent box in com_csp before users can use ist ;-) (just joking)

Thanks for all the feedback and help 👍 I now start implementing the integration part.

This functionality has been available as a 3rd party plugin for many months.

JED: System - Content Security Policy

Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4.

Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4.

Just wondering how you would feel when the core introduces a new feature which replaces part of your business. Sorry but this is not an argument to add new features to the core.

Don't get me wrong, I think this is a great addon for J4, but we have an eco system to take care of too.

Don't get me wrong, I think this is a great addon for J4, but we have an eco system to take care of too.

I get your point - but how can one solve this? Not adding such a feature isn’t an option either, right?

but how can one solve this?

Not sure what you exactly mean. But do you don't agree that the eco system with the extension is a important part of Joomla?

Not adding such a feature isn’t an option either, right?

It is all how much research was done upfront if there is no extension which solves that use case. If there is one, then I don't see the point to add it to the core.

I'm all in that the core can trace security issues and visually display them. The problem I have is that we have to be very sensitive what will be added to the core and in which way. But more importantly is how we communicate it to the community, especially from the leadership.

there are multiple commercial gdpr extensions on the jed as well

But do you don't agree that the eco system with the extension is a important part of Joomla?

Of course it is! Never wanted to question the importance of the ecosystem. But I guess we all agree that it’s not just Joomla needing a healthy ecosystem but also the ecosystem needing a healthy Joomla, so if there is a potential feature that gives us a competitive advantage (and being the first major webapp with CSP surely is one of these advantages and sends the message of Joomla taking security seriously) we should use it and bring it into core.

Yes, at the end of the day we always need to be careful and ask ourselves what belongs into core and what doesn’t. In this case I’m clearly in favor of adding it because it’s a potential fix for one of our main security issues: XSS. Joomla has a general architecture problem (using PHP as a templating engine) that can’t be easily overcome (switch to a templating language) without killing the ecosystem.

That's why I said that I like it and it's a good thing to improve security. Just comments like "Well, it’s a paid extension for Joomla 3, not quite sure how this can be compared with a free core feature for J4." can be misunderstood by the extension devs. Just wanted to raise awareness what we say where. Anyway, didn't want to make a long story out of it. Pr is merged and all is good.

As a response to @stutteringp0et:
your plugin was published on April 2018

The decision on implementing CSP in core was done over a year before you released that plugin: #14246
and the first part was also merged in core over 3 months before you released your plugin: #18301

So arguing here why core is implementing CSP when there are 3rd party solutions (introduced after the RFC) is not fair at all. The production team responded publicly on that RFC, and many contributors offered their time to implement this which also makes your comment totally unfair for them.

Also bear in mind that people who base their income on Joomla tend to give back some code as an appreciation, namely @laoneo gave custom fields, @nikosdion gave back the 2FA, the update script, fof and numerous more stuff. This is how an open source product like joomla can thrive by giving back and definitely not by holding progress back...

Guys please leave it alone here. People have made their points. Locking this topic