SimonRWaters

Without experimenting with Swift it is hard to say.

All the Security Headers plugin does is write the headers with PHP at the appropriate events.

Some caching plugins can (optionally) cache these headers. If the cache plugin removes the security headers it is because it is side stepping the usual WordPress events. But otherwise the headers shouldn’t impact caching (other than the usual impact of HTTPS on caching).

I’d still suggest caching plugins are the wrong approach to WordPress performance, CDNs and generic reverse proxies (Varnish, HAProxy,Squid etc) are what I’ve done in the past. They aren’t tied to just WordPress content, and CDNs can address DDoS threats.

If you know the web host technology and have permission you can use htaccess files (or the web server config, some web servers can also do a basic proxy where static content such as images & CSS are served by the web server without PHP on second and subsequent requests, but again this is getting messy), the GD Security Headers plugin among others provides a point and click approach to htaccess config for similar headers, but I’ve not used it in anger.

Can you explain where you see the error, what page, what browser etc.

Looks like the header is being sent already, and it has added “1” twice.

Do you have another plugin adding this header?

For preload they have specific requirements for the superdomain “digitalmnemes.it” as stated on thepage you linked. You may need to direct that at your WordPress instance, or other site that you control the headers for, to satisfy those conditions. It just needs a redirect to www version and have the strict transport security header with preload (so valid certificate) on the redirect.

That said even without preload a correct Strict-Transport-Security config with long max-age is still well ahead of the bulk of websites.

Okay I’ve pushed 1.1 which fixes the missing close anchor tag which is the cause of this. Please update as soon as it is available (literally added “[/a]” after the link to Scott’s website in the code).

There is some outstanding maintenance to bring other aspects up to current WordPress expectations, so I had planned on a new release this week, so they’ll be another release shortly.

• This reply was modified 7 years, 2 months ago by SimonRWaters.

The error sounds line MOD_SECURITY, which applies rules to requests to deny them.

Alas because the rules may be arbitrary you would need to contact the webhost support to understand what they are doing here.

Good question, and thanks for asking.

I haven’t reached a view on it yet.

I’ve shied away from headers which place too much complexity on the user, or are unlikely to provide substantive security improvement, or will create headaches that can’t be solved by intelligent reading of the console error messages.

For example Content Security Policies, whilst an excellent idea, really need co-ordinated action from WordPress to support than effectively, since the biggest attack surface is the admin console for XSS (and similar issues, CSRF), and that requires all plugins to be covered (or it will break plugin admin and be annoying and people will uninstall – this happens a little already – we struggle against complexity), so it really needs plugins to state their requirements on installation.

If CSP was done centrally any failure due to the CSP is either hacking, or a bug in plugin not stating its requirements, where as currently I’ve been unable to define a particularly effective CSP for my own trivial personal blog, let alone complex sites with multiple plugins.

I’m minded at the moment that Feature Policy is similar, and that the most invasive features for user privacy (like camera and microphone) are already defaulted to prompt the user in all good browsers. Thus you would look to disable Microphone if your site has a subset that permits telephony, but you don’t want a bug elsewhere in the site to permit eavesdropping because the per site permissions are too coarse. If a site doesn’t use microphones I don’t see the win in disabling it further, especially since it can be overridden in an iframe.

It may make sense to have a plugin that simply says “none, none, none..” and can be disabled if you use a feature, but I’m not sure how much that really gains end users in privacy or security.

Please do let me know your views. Especially scenarios where it makes sense, or is a clear win, may make me change my mind, as I haven’t done any thorough thinking or modeling on this.

Whilst I love sites like Security-headers.io (and Scott seems like a nice chap too) which assess security and give easy to understand scores, they are no substitute for thinking through the security gains (and costs). I will only implement the feature if it is a clear win, and not overly complex (I don’t want to be like other security tools that are so complex they introduce their own security flaws (I’ve already had one major bug although it didn’t open up new attack surface).