If we are going to do this then we should be complete and also offer CSP and STS options.

If we are going to do this then we should be complete and also offer CSP and STS options.

hmm the problem with that both things is that you can not set just one default option. But anleast for the csp there are planings beyond this PR / Plugin by the Joomla 4 team. So the system can generate a suggestion. But this should not stop this plugin as this prepare anything we can do from now.

Thanks for your other feedback. Commit is incoming ?

Agree about the issue of the default. Although it is possible to have a default value that will pass the test (I've done it) it is a crazy value

@zero-24 do you want to add STS header into this PR - i think that one is pretty easy

@brianteeman i'm going to leave CSP for a later addition to this plugin - as you know from my experience at the sprint with https://github.com/wilsonge/joomla-cms/tree/csp it was lots of pain to have a half decent CSP - i'm going to keep plugging away at it. But in the mean time I think this gives us some quick wins whilst we think about things

Re the descriptions. All the descriptions that are just long winded ways of saying the same thing as the label can be removed.

@zero-24 do you want to add STS header into this PR - i think that one is pretty easy

Sure but what default value do you suggest? And as we don't force https on new sites it need to be per default disabled anyway.

All the descriptions that are just long winded ways of saying the same thing as the label can be removed.

Sure. The question is what are our target users. Does a "normal" enduser understand what the setting means or not?

Sure but what default value do you suggest? And as we don't force https on new sites it need to be per default disabled anyway.

I think we don't need on/off - we can use the main application values for force https? All we need to do is have the time till expires in the plugin which is configurable (by default probably a month - 2592000 seconds)

I think we don't need on/off - we can use the main application values for force https? All we need to do is have the time till expires in the plugin which is configurable (by default probably a month - 2592000 seconds)

Please check https://github.com/joomla/joomla-cms/pull/18301/files#diff-660b387da9d45a7ecca4cd27e25b3280R126 is it that what you had in mind?

Should we include the includeSubDomains setting too?

I have skipped the option part and allow now to overwrite the values using the additional headers i think this keeps the options low.

Please check https://github.com/joomla/joomla-cms/pull/18301/files#diff-660b387da9d45a7ecca4cd27e25b3280R126 is it that what you had in mind?

Seems good to me!

Should we include the includeSubDomains setting too?

Umm I wouldn't do includeSubDomains - we're only concerned about the current Joomla site - no more

If i read this correctly, the default headers will be enabled even for updated 3.x installs, correct? If so, we should all have in mind that this might be experienced as a backwards breaking change for users that are running their site in an iframe (I know a number of hosts who implement "redirects where the original domain stays the same" using an iframe) and make sure that this is documented properly.

PLG_SYSTEM_HTTPHEADER_XFRAMEOPTIONS_DESC and the following descriptions are great examples of !eaningless strings. They don't say anything. And if your argument is that they are useful for less technical users then they are worse than useless as they are without any useful information (which should be in docs not tooltips anyway)

Default on will be a problem. No question about that.

#18301 (comment) no we can't use the force HTTPS value in global config. On a good server you do not (and should not) use that

@SniperSister you didn't because the PR is against 4.0 branch :)

@wilsonge sure, but 3.x sites will be updated to 4.x in the future too? ;)

Security headers are great and its great that we will have a way to implement them in joomla.

However they really are not something that should be enabled by default - even with what you think are sensible settings. Especially as because when security headers block something from loading you do not get an error message indicating where the issue is.

If you think of the content security we have right now with creating xframes in the weysiwyg editor and how many issues this creates on the forum - and now massively multiply it you should get the idea.

I've been fortunate to meet and hear Scott speak a few times and I am confident he would agree that security headers should be something that you implement on your web site consciously from a position of knowledge and understanding.

For example one of my sites has security headers and an A rating yet it also has a policy to allow in-line styles which is kind of crazy - but that was my informed choice - otherwise my site would have broken.

For the default enabled issue we can go the postinstall message for upgrades and default enabled for new installs.
Can we agree on that? I can build it than like this.

For the descriptions i can drop them.

Sure the csp's need to be set on a informed choice. This is the reason i have not implemented a default value and told above that this (suggesting a value) is out of scope for now ;-)

As for the HSTS imo the same applys but i have implemented the poc based on georges comment. For me we can and should drop that default too as this should be a informed choice too. As this also comes with consequences.

We could have the plugin default enabled with all the default values being empty and a post installation message. This will people the time to understand and make informed choices without breaking their sites. Otherwise we are making everyone do that first before testing their shiny new J4 site which we know they will want to do BEFORE looking at messages - especially hard ones they won't understand and where the best resource for information, Scott's site, is in English only.

no we can't use the force HTTPS value in global config. On a good server you do not (and should not) use that

@brianteeman Since when? I was under the impression this should be enabled if you're in SSL mode?

If you're using the web server to force SSL you don't need to turn on the option in the CMS config.

But it doesn't hurt right? I mean I don't see the point of adding another parameter for this when we have one. Even if you're doing it at .htaccess level it just doesn't change anything

hmm isn't the bigger point the "informed decision" as this is not just a enable that header or not decision. As this can also result into implications that can come after enable that header.

If you are doing it at htaccess level then you cannot use the if statement - that is all i was saying. I was not saying that you cannot use Strict-Transport-Security or that you shouldnt use it. Just that you cannot rely on checking for forcessl

Ok just combine both notes we keep the Strict-Transport-Security out of the default handling. So everyone can do a informed decision on this one.

Can we move forward now? What other points we need to checkout / fix / correct? Or can we start testing?

Nice plug-in, that's cool, thanks @zero-24

I was wondering, if people think it'd be useful to provide granular CSP support. This is best explained by the Mozilla docs at https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

I was at a great talk at the ScotlandPHP conference by Matt Brunt (@Brunty) about how to implement CSP, so I was tinkering with these options on the way home.

I was wondering, if people think it'd be useful to provide granular CSP support. This is best explained by the Mozilla docs at https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Did you try the plugin? What kind of granular CSP support do you want to see? Thanks.

@zero-24 could you have a look at the code style issues, thanks

Drone is happy now @rdeutz

Hi @zero-24
Sorry for the slow reply, re...
Did you try the plugin? What kind of granular CSP support do you want to see? Thanks.
...Yea, I tried the plug-in, it's cool, nice and simple to set-up.

I was thinking about all content types having a separate setting.

This is pretty much based on a site admin work-flow like...

1. Set the site to content="default-src 'self';
2. See what's broken
3. Fix broken things one at a time, like content="default-src 'self'; script-src 'self' *.google-analytics.com " to let google analytics work.

In practice an admin would probably do this with Content-Security-Policy-Report-Only and just review the reports.

The simplest way to explain is maybe via a screen grab of a a plug-in I wrote...

...this is from...
https://github.com/AndyGaskell/joomla_plugin_contentsecuritypolicy
...I realise this is quite a different approach, more control and flexibility, but maybe too complex.

I'm not sure what the best solution is, but thought it might be helpful to add it to the discussion re CSP implementation in Joomla.

Are you heading to JWC? If you are, be happy to chat about it there.

Are you heading to JWC? If you are, be happy to chat about it there.

No. please contact me using Glip ?

Installed with your branch and got this error:

Fatal error: Declaration of PlgSystemHttpHeader::getSubscribedEvents() must be compatible with Joomla\Event\SubscriberInterface::getSubscribedEvents(): array in C:\xampp\htdocs\joomla-cms-4.0-dev\plugins\system\httpheader\httpheader.php on line 20

@Quy should be fixed with the last commit.

Let's see how this goes for now :)

❤️

Is there a reason why all the language strings are in the .sys.ini language file and not spread across two language files as normal

see: #19449 @brianteeman

Hello, I am not a coder, but you guys have hidden the csp and x-frame policies, which are creating duplicate entries, when someone uses alternate security software to protect a Joomla domain. Your csp entries are considered insecure, and may be creating a conflict that disables the administrator save/save&close/close button functions.

I haven't had my shared hosting website taken offline since installing this software https://securitycheck.protegetuordenador.com about 4 years ago. That is more than I can say for any Joomla development! I don't know if my sites were hacked from the shared hosting platform or not, but they have been fine since I have added that security.

Whatever you have created, please make it visible and adjustable, or remove it, as there are better options.

Regards,
Louis

@Timeforsmilin can you please open a new Issue? Comments on closed Issues didn't get much Notice.

What would cause this plugin to stop working?
Everything is enabled and it's the latest version.
None of the code is showing up on my website
I've uninstalled and reinstalled the plugin, but still no luck

Using Joomla 3 (to be upgraded), PHP8

This here is the J4 version of the plugin this can not be installed into 3.x please use https://github.com/zero-24/plg_system_httpheader within J3.

After activation the plugin configuration has to be adjusted to meet your requirements feel free to follow: https://github.com/zero-24/plg_system_httpheader/blob/master/README.md

I'm already using use https://github.com/zero-24/plg_system_httpheader but it's not working and I don't understand why?

From: Tobias Zulauf @.>
Sent: Wednesday, April 12, 2023 9:25 AM
To: joomla/joomla-cms @.>
Cc: dialanerd @.>; Comment @.>
Subject: Re: [joomla/joomla-cms] [4.0] [plg_system_httpheader] Implement security http headers per default and create the posibility to add custom http headers (#18301)

This here is the J4 version of the plugin this can not be installed into 3.x please use https://github.com/zero-24/plg_system_httpheader within J3.

After activation the plugin configuration has to be adjusted to meet your requirements feel free to follow: https://github.com/zero-24/plg_system_httpheader/blob/master/README.md

Reply to this email directly, view it on GitHub#18301 (comment), or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6YTKUTKABVARNC4NMP2HNDXAZRF3ANCNFSM4D6STSPQ.
You are receiving this because you commented.Message ID: @.@.>>

I'm not seeing any of the plug-in's settings in my headers.

From: Tobias Zulauf @.>
Sent: Wednesday, April 12, 2023 9:25 AM
To: joomla/joomla-cms @.>
Cc: dialanerd @.>; Comment @.>
Subject: Re: [joomla/joomla-cms] [4.0] [plg_system_httpheader] Implement security http headers per default and create the posibility to add custom http headers (#18301)

This here is the J4 version of the plugin this can not be installed into 3.x please use https://github.com/zero-24/plg_system_httpheader within J3.

After activation the plugin configuration has to be adjusted to meet your requirements feel free to follow: https://github.com/zero-24/plg_system_httpheader/blob/master/README.md

Reply to this email directly, view it on GitHub#18301 (comment), or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6YTKUTKABVARNC4NMP2HNDXAZRF3ANCNFSM4D6STSPQ.
You are receiving this because you commented.Message ID: @.@.>>

Ok please create an issue on that repo and include some more details about what you have done, how the plugin configuration looks right now, what is the URL and what you expect. This is the repo for the J4 implementation. Thanks.

Will do, how / where do I do this?

From: Tobias Zulauf @.>
Sent: Wednesday, April 12, 2023 9:39 AM
To: joomla/joomla-cms @.>
Cc: dialanerd @.>; Comment @.>
Subject: Re: [joomla/joomla-cms] [4.0] [plg_system_httpheader] Implement security http headers per default and create the posibility to add custom http headers (#18301)

Ok please create an issue on that repo and include some more details about what you have done, how the plugin configuration looks right now, what is the URL and what you expect. This is the repo for the J4 implementation. Thanks.

Reply to this email directly, view it on GitHub#18301 (comment), or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6YTKUWBTD7X5C3YWHSHWULXAZS3RANCNFSM4D6STSPQ.
You are receiving this because you commented.Message ID: @.@.>>

https://github.com/zero-24/plg_system_httpheader/issues please