Forum Replies Created

Viewing 15 replies - 1 through 15 (of 51 total)
  • Plugin Author 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.

    Yes, I also pinged the WordPress plugin email address, suggesting this is a class of error that should be caught before release. Slightly surprised it wasn’t.

    As far as I know short tags are both enabled by default and deprecated now.

    This was the closest I found on a quick look…

    There is no good answer if the ini settings mustn’t change the language other than to remove short tags as they are incompatible with other languages and mark-up, so if you do anything but remove them you risk silently breaking more than removing them. Either way developers need to avoid edge cases and address all warnings, I’m working on a test suite for my own plugin which would have spotted this, clearly need to pull my thumb out and get it released.

    • This reply was modified 5 months, 4 weeks ago by SimonRWaters.

    Just cleaned up same here. I went with “mv gigpress /somewhere-outside-wordpress”.

    Looks like the preceeding “if” block is missing the “?php” to denote PHP.

    I believe you can configure PHP not to require it, likely what the author has done, allowing them to release code that doesn’t parse.

    diff oldshows.php shows.php
    < <? if ( ‘deleted’ === $scope ) : ?>

    > <?php if ( ‘deleted’ === $scope ) : ?>

    php oldshows.php
    PHP Parse error: syntax error, unexpected ‘else’ (T_ELSE) in /home/simon/gigpress-broke/admin/oldshows.php on line 288

    php shows.php produced no such error.

    Plugin Author SimonRWaters


    Looks like it is nginx appending its value to the header set by the plugin.

    I think the best option is to disable (untick) the header in the plugin settings, since it is being processed by nginx after the PHP is done.

    If you can get me the nginx config it would be handy to check.

    It is going to be hard to reliably test for this in the plugin, since if there is a proxy in front mangling the headers it may not be visible from PHP. The best I could do is send JavaScript to the client browser to make additional requests (probably not a bad idea for testing if the plugin is working as expected).

    Plugin Author SimonRWaters


    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?

    Plugin Author SimonRWaters


    The plug-in doesn’t try and address Content-Security-Policy, as this would require adjustments for themes and plug-ins, and be difficult to manage for unskilled users.

    The other headers are covered. Ideas on how to do CSP without bewildering people welcomed.

    Plugin Author SimonRWaters


    For preload they have specific requirements for the superdomain “” 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.

    Plugin Author SimonRWaters



    it looks like you have WordPress 5.2.3, I tried on recent WordPress and the plugin worked there, the plugin uses the standard approach to saving settings in WordPress and is working for me, so likely something in your environment.

    If you open up the developer tools (Ctrl + Shift + i in Chrome), pick the “Network” tab, and then load the settings page, when you save settings you should see an “options.php” request added to the network list, you should see a “302 Found” in the source view of the Response Header, and you should see your settings in parsed “Form Data” section.

    Should look something like this:

    Take a look at that, and check the “error log” from your WordPress host for entries that appear when you submit the settings you want. If it is getting something other than “302 Found” it could be a Web Application Firewall triggering, or similar.

    If you do need to share a screenshot be careful to make sure you aren’t sharing any cookie entries in the requests/response, as that could include the cookie that makes you WordPress admin (and you don’t want to share that to everyone).

    Plugin Author SimonRWaters


    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 2 years, 5 months ago by SimonRWaters.
    Plugin Author SimonRWaters


    Embarrassingly no, looks like it broke in a recent update to WordPress, as my blog is broken too.

    On it, thanks for the report.

    Plugin Author 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.

    Plugin Author SimonRWaters


    Thanks for the question.

    The plugin is currently entirely self contained, and there is no direct storage of personal data, and so no direct GDPR implication. There is no inclusion of third party hosted code or images, and no tracking.

    The plugin does allow setting of reporting URI for Certificate Transparency and Public Key Pinning violations, but you would have to provide or acquire 3rd party services to use this feature ( for example). The data stored in such services is typical of that required to resolve technical issues or identify misuse (including potential criminal activity). I would imagine such services have no or miminal GDPR implications but I am not a lawyer, you might want to include this activity in a comprehensive privacy statement.

    Some documentation, such as how to do Public Key Pinning is provided via my personal blog that records standard W3C style logging of web requests (date/time, IP, browser user-agent, and referrer).

    Plugin Author SimonRWaters


    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 (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).

    Plugin Author SimonRWaters


    Glad to hear you resolved it.

    I will review the documentation, it all exists, but may need to be more prominent.

    Plugin Author SimonRWaters


    Not sending referrer headers is common, so I don’t think it signals anything bad.

    Yes, disabling them can break stuff, including tracking.

    The plugin exposes the possible policies, it doesn’t say which is right for your site.

    Some browsers and browser plugins, also restrict referrer headers. So avoid relying on them where it can be avoided.

Viewing 15 replies - 1 through 15 (of 51 total)