Hardening WordPress: Best Practices for Content Security Policy (CSP)

WordPress powers a massive portion of the web, making it a prime target for Cross-Site Scripting (XSS) and data injection attacks. Implementing a robust Content Security Policy (CSP) is one of the most effective ways to restrict exactly where scripts, styles, and resources can be loaded from. However, because WordPress relies heavily on third-party plugins and themes, a poorly configured CSP can easily break your site’s functionality.

Here is how to deploy a secure CSP in WordPress without breaking your frontend layout.

1. Begin with Report-Only Mode

Never deploy a strict CSP straight to production. Instead, utilize the Content-Security-Policy-Report-Only header. This instructs the browser to log policy violations to a reporting service (such as UriPorts or Report-URI) without actually blocking any resources. This allows you to safely discover what external assets your plugins are trying to load.

// Add a Report-Only CSP header via your theme's functions.php
add_action('send_headers', 'add_csp_report_only_header');
function add_csp_report_only_header() {
    header("Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted-cdn.com; report-uri https://your-subdomain.report-uri.com/r/d/csp/enforce;");
}

2. Account for WordPress Plugins and Inline Scripts

Many WordPress plugins inject inline JavaScript, which a secure CSP naturally blocks under standard rules. To fix this without resorting to the insecure 'unsafe-inline' directive, you should implement CSP nonces (unique cryptographic tokens generated per page request) or use a modern strict-dynamic approach.

Figure 1: Monitoring your browser console during the Report-Only phase helps catch blocked plugin assets before they disrupt users.

3. Whitelist Essential External Directives

If your theme fetches fonts from Google, videos from YouTube, or tracking data from Google Analytics, you must explicitly declare these domains within their respective directives (font-src, frame-src, and script-src).

// Example of a production-ready CSP header for a standard WordPress site
add_action('send_headers', 'add_production_csp_header');
function add_production_csp_header() {
    header("Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com;");
}

Figure 2: Combining a backend CSP with clean security habits ensures your WordPress core remains safe from malicious script injections.

The Verdict

Building a bulletproof CSP for WordPress requires patience. Start lax using the report-only header, audit your plugins’ external connections, and gradually lock down your directives until your site is fully secure.