Title: Security Headers
Last modified: November 10, 2017

---

# Security Headers

 *  Resolved [bsthp](https://wordpress.org/support/users/bsthp/)
 * (@bsthp)
 * [8 years, 7 months ago](https://wordpress.org/support/topic/security-headers-4/)
 * Hi! I have added the recommended Security Headers for X-XSS-Protection, X-Frame-
   Options and X-Content-Type nosniff but the reinders are still showing in the 
   Sucuri dashboard. The following code was inserted into my .htaccess file;
 * <IfModule mod_headers.c>
    Header set X-XSS-Protection “1; mode=block” Header 
   always append X-Frame-Options SAMEORIGIN Header set X-Content-Type-Options nosniff
   </IfModule>
 * Does anyone know why the messages are still appearing? Many thanks

Viewing 3 replies - 1 through 3 (of 3 total)

 *  [yorman](https://wordpress.org/support/users/yorman/)
 * (@yorman)
 * [8 years, 7 months ago](https://wordpress.org/support/topic/security-headers-4/#post-9670814)
 * > Does anyone know why the messages are still appearing?
 * There could be to answers to your question.
 * One is Cache and the other is missing Headers module.
 * **How Does The Sucuri Cache Works?**
 * There are two explicit and one implicit cache mechanism running in place during
   the execution of the web malware scanner. The first one is in your local web 
   server, controlled by the plugin, and it usually expires every 20 minutes, you
   can reset this from the “Data Storage” panel located in the plugin’s general 
   settings page, the file is called “sucuri-sitecheck.php”.
 * The second cache is controlled by SiteCheck, the server that the plugin uses 
   to scan your website. The cache here expires every 48 hours unless someone requests
   a fresh scan before the automatic flush is executed. The problem is that requesting
   a fresh scan doesn’t flush the cache, it just skips it, the cache will still 
   be served until the 48 hours period ends. In order to make the plugin show the
   fresh scan results every time it would require a modification in the code that
   would make your website admin interface load slow, this is why the cache is important,
   to prevent this slowness.
 * The third cache is implicit, and is part of another system that has little relation
   with the whole thing. This cache is controlled by the Sucuri Firewall. When your
   server sends a HTTP request to the SiteCheck API the firewall caches the request
   in one of our datacenters to serve the same request faster in subsequent attempts
   to request the same resource.
 * **What About The Apache Headers Module?**
 * The rules that you included in your access control file are wrapped around a 
   condition that checks if the Apache headers module is enabled, otherwise the 
   instructions inside that block are ignored. If you can verify that the module
   exists and is enabled then we can assume that the cache is the culprit, otherwise
   I suggest you to communicate with your hosting provider to ask for alternatives
   to include those headers. You can also include them using PHP but it requires
   the modification of one of the WordPress core files so I prefer not to teach 
   you how to do it.
 * The cache will be flushed after 48 hours, you can ignore the warnings for now.
 *  [thpword](https://wordpress.org/support/users/thpword/)
 * (@thpword)
 * [8 years, 7 months ago](https://wordpress.org/support/topic/security-headers-4/#post-9670855)
 * Thanks for your update. I was just about to post an update myself. Being on a
   Shared Hosting Platform, it appears my Hosting supplier does not allow these 
   types of requests, so it is an issue at my end. By the way, I use Heartinternet,
   in case any other readers of this post are with them also. This update is from
   bsthp.
    -  This reply was modified 8 years, 7 months ago by [thpword](https://wordpress.org/support/users/thpword/).
    -  This reply was modified 8 years, 7 months ago by [thpword](https://wordpress.org/support/users/thpword/).
 *  [yorman](https://wordpress.org/support/users/yorman/)
 * (@yorman)
 * [8 years, 7 months ago](https://wordpress.org/support/topic/security-headers-4/#post-9670897)
 * As an alternative, you could include the security headers directly from a PHP
   script, however, because this requires the modification of one of the core WordPress
   files it may not be the best solution but can achieve the same results:
 *     ```
       <?php
       header('X-Frame-Options: SAMEORIGIN');
       header('X-XSS-Protection: 1; mode=block');
       header('X-Content-Type-Options: nosniff');
       ?>
       ```
   
 * Adding this piece of code at the top of the main `index.php` file works.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Security Headers’ is closed to new replies.

 * ![](https://ps.w.org/sucuri-scanner/assets/icon-256x256.png?rev=2875755)
 * [Sucuri Security - Auditing, Malware Scanner and Security Hardening](https://wordpress.org/plugins/sucuri-scanner/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/sucuri-scanner/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/sucuri-scanner/)
 * [Active Topics](https://wordpress.org/support/plugin/sucuri-scanner/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/sucuri-scanner/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/sucuri-scanner/reviews/)

## Tags

 * [sucuri](https://wordpress.org/support/topic-tag/sucuri/)

 * 3 replies
 * 3 participants
 * Last reply from: [yorman](https://wordpress.org/support/users/yorman/)
 * Last activity: [8 years, 7 months ago](https://wordpress.org/support/topic/security-headers-4/#post-9670897)
 * Status: resolved