I was thinking a bit about CSP (“Content-Security-Policy”) plugins.
I have a few very basic plugins I have developed for my own website projects. They do not yet have user-settings capabilities as I have not yet gotten “to that level” of “Press”-programming.
I have one for using CSP (which even generates and inserts script and style NONCEs into the HTML document before sending to the browser).
I also have a very simplistic Security-Headers plugin to set the other security headers.
I wasn’t sure if anyone here already had suitable plugins for those features under “ClassicPress”, but I am willing to give it a try - if not. I have the “skeleton code”, with the settings hard-coded for now, as those specific settings are what I use currently.
I will upload these to my CodeBerg repositories shortly. I still must test the basic coding to see if they will work properly with ClassicPress (even though, they should have no problems).
Can you post some links to reference material about CSP and security headers, so anyone interested can give a more enlightened feedback?
Is it good practice to combine these or have separate plugins?
From me you’d get a yes vote on developing this if you have the time.
I have a custom site level plugin that implements harder headers and CSP on my sites, it takes some effort though, so even with a plugin it would have a high barrier for entry - lots of external links and screens need ‘allowing’ or the site will break.
I think it would be a welcome addition and there is at least one plugin in the WP repository that does this,
I implement CSP headers on all my sites manually, so I definitely think this is an important area to address. Getting the UI and UX right to be able to explain the settings in a plugin is likely to be quite a challenge but, if you’re up for it, go for it!
Scot Helme does a great job of explaining the details - as he has become a well-renowned “security expert” on this and other related security matters. He also runs a site which you can use to check your site if it is setting the needed headers - at: https://securityheaders.com.
As far as one or more plugins - that is a good question!
It may be preferable to have an “all-in-one plugin” for some, but not necessarily for others. This depends on you and/or your clients’ particular needs - AND if there are other means by which one or more of these particular header fields are set - and what values they are set to.
I was looking at doing a CSP plugin on its own, and the other security headers in a separate plugin. However, because the Permissions Policy header is becoming more involved and having more detailed values for settings, it may get its own plugin - if I code one for it.
The other basic security headers like for “X-Frame-Options”, “X-Content-Type-Options”, and other single-value/single-setting type headers can easily be dealt with in an all-in-one plugin. - Just MHO, anyway. Others’ views may differ.
Using a well-coded plugin would help simplify the task of setting and configuring the security headers. Plus, any time you needed to change any of the settings (like for supporting an added API, or another site with the remote-loaded resources you are using - being added), this could be more easily done from a settings page, and then the changed settings saved to the DB to be used on successive loads of your webpages.
This would be my very first undertaking, as far as the UI/UX and DB-access end of it. I only have the basic, hard-coded values set within a basic coding framework as of now.
I may be asking for some assistance on the UI/UX and DB-access end - from those who have had experience in developing plugins, fairly soon. I know there are great guides already published on the subject, but I am not currently able to afford those resources right now.
Well, well! - Appreciate the well-wishing support!
“Time” is what is going to be the determinant. I have the basic “engine” of the plugins figured out, just not the UI/UX and DB functions yet.
I tested a few of the WordPress plugins a couple of years ago - and was a little disappointed, for differing reasons. One plugin made changes to the .htaccess file - to place the CSP settings there. - No, no, no! - You DON’T want the CSP headers sent with every resource subrequest also, because this would be pointless - as ONLY the initial CSP headers sent with the HTML page will be used by the user-agent (“browser”) to tell it how to handle those resources sub-requested. Plus, htaccess-based CSP rules also limit your ability to make effective use of scripting/style-NONCEs, because your htaccess files should not change upon each web-request anyway. - So this was my “strike” against one of the plugins - as an example.
A couple of others just didn’t seem to work at all.
Therefore,
I was looking at a genuinely stable, fully-functional set of plugins (or just ONE plugin - if I can manage that effectively).
Mr. Scot Helme is not the only one who has “done his homework” when it comes to effectively using browser security-headers.
So yeah,
It will be a worthy project - IF - I can “get it off the ground” in good time. I’m sure it will be fun.
It’s best to code it incrementally anyway. Plan on using a single database entry, so the options table is not polluted. Then figure a good way to present the options, whether that is all on one page or tabs in a page. Find a well-written plugin that you like and read their code for their settings page. It’s not that difficult.
You can use the Settings API if you think others will add more (separately), or avoid all that and output your fields yourself. Along with built-in functions for sanitizing, nonces, and capability checks, there is get_option and update_option, so it’s straightforward.
I still have to get to “first base” on this. The functional “engine” side of things, I already have working. It’s just a matter of making all the settings into user-settable options. - This I’m not too familiar with yet, but I will at least try it.
