New to the community? Start here

Cannot Revert X-Content-Type-Options Security Header – Troubleshooting Conflict

Can’t seem to revert a Defender setting. Attempting to troubleshoot a conflict with Defender and Store Locator Plus. Trying to not deactivate Defender completely.

I have definitely narrowed it down to Defender and by deactivated Defender Store Locator Plus’s ADD feature works again.

Cannot Revert X-Content-Type-Options Security Header. The button is there but it doesn’t revert. I don’t know where I can do this manually as it’s not an .htaccess setting so I assume a DB entry or the like. It doesn’t go away after a RESET of Defender or an uninstall and reinstall.

To be clear. Going to Store Locator Plus with Defender activated will not show the screen that comes up under Add.

Tue, 11 Feb 2020 10:12:30
More Defender Pro discussions
Defender Pro
  • Adam
    • Support Gorilla

    Hi ctgreno

    I hope you’re well today and thank you for getting in touch with us!

    We’ve already asked our developers for consultation on this but meanwhile I’d like to ask you for one more thing.

    This tweak “status” (whether it’s enabled or disabled) is stored in options in database. So the plugin checks if it is supposed to be enabled and simply appends HTML header directly to the content that’s generated by WordPress.

    This, however, means also that it might be “sensitive” to cache:

    – option status might fall into the object cache if there’s such cache on server (as it stores some db data)
    – or it might get “cached” somewhere on the way – especially if there’s CloudFlare or similar CDN used.

    So, did you try to revert the tweak and then clear all possible caches that you can find on server (if there are any), on site (if there’s any caching plugin/feature active) and in CloudFlare?

    Best regards,
    Adam

  • ctgreno
    • Flash Drive

    Greetings,

    We’ve done all cache flushing, turning off caching, double-checking that there is nothing cached, and then making sure again. We use Cloudflare and Hummingbird but neither seems to make a difference – on/on, off/on, on/off, off/off – any variation.

    What I was hoping to do is add the exceptions but that wouldn’t work either.

    At this time we just deactivate Defender, edit the stores, and then activate Defender.

  • Adam
    • Support Gorilla

    Hi ctgreno

    Thank you for your response and for giving it a try!

    It was worth a try but since it didn’t work, we’ll need to wait for the feedback from our developers after all. I’d appreciate some patience as their response time might be longer than ours here on forum – they’re dealing with multiple complex tasks on daily basis.

    We’ll update you here as soon as we get to know more from our devs.

    Best regards
    Adam

  • Alessandro
    • Nightcrawler & Daydreamer

    Hello ctgreno!

    Defender adds headers to your WordPress site via PHP header() function. To check if a Security Tweak has been applied, Defender fetches headers via wp_remote_head() and checks which header exists or not. If a security header (X-Content-Type-Options, X-Frame-Options etc) exists then it adds it to the resolved tweaks.

    If you add a Security Header as configuration setting to your server (e.g. in .htaccess file), which I think is your case, then Defender always detect that header and adds it to the resolved tweaks making it “unrevertable“.

    Another way to check if this issue is caused by Defender or even by WordPress, try to make a test with a static file. Every WordPress installation comes with a “readme.html” file. This is a static file and no PHP or DB query take place to serve it. It is being served as it is. If you hit “/readme.html” in your browser you will see that page.

    Inspecting this page with Developer Tools we see under Response Headers on Network that “x-content-type-options: nosniff” is still there. That makes me confident to say that it’s not related to Defender and you should check these configuration with your host. (Screenshot attached) :blush:

    Note: If you are using third-party services to proxy your website (like CloudFlare), consider checking the current settings as they may modify part of your headers.

    What I’d like is DB locations for performing a complete deletion of Defender Pro if you are able to get those to me.

    This is a completely dangerous action! Defender uses WordPress’s options table to store key-value settings. Data may exist in other tables too (like defender_lockout, defender_lockout_log etc). As plugin is being developed the schema of the data that exist on the database changes. We strongly recommend to set “Data -> Remove” option under “Uninstallation” tab on Defender’s “Data & Settings” page. Deleting directly data from the database do not honor the data model and any leftovers may cause further issues. In any cause you can find the procedure of data deletion on “uninstall.php” file.

    I hope this helped you out to understand what is going on with Defender and Security Headers.

    Let us know if you need further assistance.

    Kind regards,
    Alessandro.