How to Fix Security Headers in WordPress

WordPress powers ~43% of the web — and adds zero HTTP security headers by default. It also broadcasts its version via a <meta name="generator"> tag on every page, giving attackers a one-step path to known CVEs. This guide walks through fixing every WordPress-related finding from our Security Audit: removing the version meta, adding the six security headers, hardening wp-config.php, and dealing with cookies. Works on WordPress 6.x and any hosting environment.

1. Remove the WordPress generator meta tag

By default, WordPress adds <meta name="generator" content="WordPress 6.4.2"> to every page's HTML head. That single line tells anyone — including automated CVE scanners — exactly which version of WordPress you're running. Remove it.

// Remove WordPress version from generator meta
remove_action('wp_head', 'wp_generator');

// Also strip version from CSS and JS file URLs
function aw_remove_version_from_assets( $src ) {
    if ( strpos( $src, 'ver=' ) ) {
        $src = remove_query_arg( 'ver', $src );
    }
    return $src;
}
add_filter( 'style_loader_src', 'aw_remove_version_from_assets', 9999 );
add_filter( 'script_loader_src', 'aw_remove_version_from_assets', 9999 );

// Remove version from RSS feeds
add_filter( 'the_generator', '__return_empty_string' );

2. Add HTTP security headers

Six headers cover the audit's HTTP Security Headers section: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. The best place to add them depends on your hosting.

If you control the web server (recommended)

Adding headers at the nginx or Apache layer is faster than at the PHP layer. See the Plesk fix guide or the upcoming nginx/Apache/cPanel guides for server-level instructions. WordPress works correctly behind any of these.

If you cannot edit server config — use functions.php

On managed WordPress hosting where you can't touch nginx or Apache, add headers via the send_headers action:

add_action( 'send_headers', function() {
    header( "Strict-Transport-Security: max-age=31536000; includeSubDomains" );
    header( "X-Frame-Options: SAMEORIGIN" );
    header( "X-Content-Type-Options: nosniff" );
    header( "Referrer-Policy: strict-origin-when-cross-origin" );
    header( "Permissions-Policy: geolocation=(), microphone=(), camera=()" );
    header( "Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; frame-ancestors 'self'" );
});

3. Harden wp-config.php

Several security wins happen in wp-config.php — the WordPress configuration file in your site's document root. Edit via SFTP or your hosting file manager.

define( 'DISALLOW_FILE_EDIT', true );

define( 'FORCE_SSL_ADMIN', true );

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

4. WordPress cookie flags

WordPress sets a handful of session cookies (wordpress_, wordpress_logged_in_, wp-settings-). The audit checks for Secure, HttpOnly and SameSite flags. WordPress sets HttpOnly correctly by default. Secure depends on your HTTPS configuration. SameSite is the modern gap.

Add this to functions.php to enforce all three on WordPress's session cookies:

add_action( 'init', function() {
    if ( ! headers_sent() ) {
        $secure   = is_ssl();
        $httponly = true;
        $samesite = 'Lax';
        session_set_cookie_params([
            'lifetime' => 0,
            'path'     => COOKIEPATH ?: '/',
            'domain'   => COOKIE_DOMAIN,
            'secure'   => $secure,
            'httponly' => $httponly,
            'samesite' => $samesite,
        ]);
    }
});

For cookies set by plugins, you may need to also add header-level overrides via your web server, since WordPress can't retroactively modify cookies third-party code has already sent.

5. Remove WordPress fingerprint files

WordPress ships with several files that broadcast its presence even if you remove the generator meta. They aren't strictly required and can be deleted or 404'd.

Block XML-RPC if you don't use Jetpack, mobile WordPress apps or any service that requires it:

// In .htaccess (Apache) — return 403 for /xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

6. The WordPress version is still in CVEs — keep it updated

Removing the generator meta hides the version from casual fingerprinting, but the actual CVE risk only goes away when you patch. The audit's CVE check via NVD will not flag WordPress on a clean site without an exposed version. But that doesn't mean you can skip updates — set WordPress core, plugins and themes to auto-update major releases. Add to wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', true );

Frequently Asked Questions