POST /?wordfence_syncAttackData= conflicts with nosniff header

Hi @prestonwordsworth,

Which errors you seeing specifically in the browser console? We will of course explore any issues that could affect you and other customers, but I have seen nosniff present on other sites running Wordfence successfully.

The wordfence_syncAttackData script is a normal process run by Wordfence to ensure your malware signatures and rules are up-to-date with the latest ones we have released. They’re only called from the browser if Wordfence can’t sync automatically, usually meaning that the site can’t reach itself. That might suggest there is another problem with the server configuration, Cloudflare, or firewall stopping Wordfence rather than the header.

You can check whether the site can reach itself at Wordfence > Tools > Diagnostics under “Connecting back to this site“. If it can, your site might just be seeing a heavy amount of access attempts. 403 or 503 blocks by the firewall trigger the need to sync, so seeing this process triggered with an HTTP error code is usually expected. This doesn’t affect site performance itself, although if your site is being hit hard then it may slow down as a side-effect.

Many thanks,
Peter.

Apologies for the delay. I’ve just had time to look at the code, so here’s why your script is being blocked by browsers:

if ($attempts > 10) {
    add_action("wp_head", "wordfence::addSyncAttackDataAjax");
    add_action("login_head", "wordfence::addSyncAttackDataAjax");
    add_action("admin_head", "wordfence::addSyncAttackDataAjax");
} else {
    update_site_option("wordfence_syncAttackDataAttempts", ++$attempts);
    wp_remote_post(
        add_query_arg(                  
            "wordfence_syncAttackData",
            microtime(true),
            home_url("/")                                               
        ),
        [
            "timeout" => 0.01,
            "blocking" => false,                                                                
            "sslverify" => apply_filters("https_local_ssl_verify", false),
        ]
    );                                  
}

The second method is OK because wp_remote_post is a loopback request that bypasses the browser. The trouble is with the first method, which gets triggered like you say when there’s a bout of attacks. Let’s see what it’s doing:

public static function addSyncAttackDataAjax() {        
        $URL = home_url('/?wordfence_syncAttackData=' . microtime(true));        
        $URL = esc_url(preg_replace('/^https?:/i', '', $URL));        
        // Load as external script async so we don't slow page down.        
        echo "<script type=\"text/javascript\" src=\"$URL\" async></script>";        
}

So that’s why it’s getting blocked! The type attribute won’t work as intended when a site is using a caching solution that’s set to ignore query strings, a common technique to obviate query string-based DDoS attacks. That’s because a request like this would simply return the cache of home URL with a MIME type of text/html, triggering a nosniff block by browsers:

Refused to execute https://www.example.com/?wordfence_syncAttackData=1728611106.9776 as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type.

What we would like to see is a toggle that lets webmasters to opt out of this ‘script’ method on sites that have this rather common setup.