Last month, a routine plugin update almost turned into an incident report.

Nothing dramatic happened on the surface. Checkout worked, login worked, traffic looked normal. But while reviewing browser logs for an unrelated issue, I noticed a third-party script request I did not recognize. It was not malicious in that moment, but it was unreviewed JavaScript running in a production page with real user sessions. That was enough. We had already tightened server and WordPress basics, but the browser still had too much freedom.

That week, I rolled out a WordPress strict CSP policy in stages. The key was not writing a perfect policy on day one. The key was introducing guardrails gradually, collecting real violations, and only then enforcing. This guide is the process I wish I had followed earlier.

Why this mattered more than another hardening plugin

CSP is not a silver bullet, and it does not replace secure coding. But it changes the blast radius of XSS. If an attacker finds an injection point and your browser policy is weak, they can often execute arbitrary JavaScript. A strict policy based on nonces or hashes makes that path significantly harder.

For 7tech-like WordPress stacks, CSP adds a browser-side layer that complements server work from our WordPress hardening checklist and host-level controls similar to our hardened SSH bastion setup.

What “strict” means in practical terms

A strict policy is usually nonce- or hash-based, not a giant allowlist of script domains. The tradeoff is clear:

• Allowlist CSP: easier to start, easier to bypass when it grows messy.
• Nonce/hash CSP: harder rollout, better resistance to script injection classes.

For dynamic WordPress pages, nonces are usually the better fit because pages are server-rendered and can inject a fresh random nonce per response. For static builds, hash-based policies can be cleaner.

My primary keyword for this article is WordPress strict CSP. Secondary keywords I used naturally are script nonce WordPress, Content-Security-Policy-Report-Only, and CSP violation reports.

The rollout playbook I used (without breaking analytics)

Phase 1, deploy in report-only mode

Start with Content-Security-Policy-Report-Only. You will immediately discover dependencies no one documented, including tag managers, embedded widgets, and admin-side scripts bleeding into frontend templates.

# Nginx example: report-only first
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'nonce-$request_id' 'strict-dynamic'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https:; font-src 'self' https: data:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; form-action 'self'; report-uri https://www.7tech.co.in/csp-report" always;

Important: $request_id is convenient in Nginx, but use a cryptographically strong per-response nonce generated by application logic when possible. If your edge nonce and script tag nonce mismatch, scripts will fail.

Phase 2, wire nonce into WordPress script tags

WordPress gives enough hooks to add a nonce attribute to enqueued scripts. I used a small mu-plugin so updates could not accidentally disable it.

<?php
/**
 * mu-plugins/csp-nonce.php
 */

add_action('send_headers', function () {
    if (is_admin()) {
        return;
    }

    $nonce = base64_encode(random_bytes(16));
    $GLOBALS['csp_nonce_value'] = $nonce;

    header(
        "Content-Security-Policy: default-src 'self'; " .
        "script-src 'self' 'nonce-{$nonce}' 'strict-dynamic'; " .
        "style-src 'self' 'unsafe-inline'; " .
        "img-src 'self' data: https:; " .
        "connect-src 'self' https:; " .
        "font-src 'self' data: https:; " .
        "object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'"
    );
});

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    if (is_admin()) {
        return $tag;
    }

    $nonce = $GLOBALS['csp_nonce_value'] ?? '';
    if (!$nonce || strpos($tag, ' nonce=') !== false) {
        return $tag;
    }

    return str_replace('<script ', '<script nonce="' . esc_attr($nonce) . '" ', $tag);
}, 10, 3);

Two caveats from real usage:

• If a caching layer serves stale HTML with a stale nonce while headers are fresh, CSP breaks. Vary or bypass cache where nonce injection happens.
• Inline event handlers like onclick still fail. Replace them with proper event listeners.

Phase 3, clean up noisy violations

This is where most teams quit too early. CSP violation reports are noisy at first. Browser extensions, old bookmarked URLs, and deprecated scripts can flood logs. Group by directive and source, then fix by frequency and user impact.

We used the same risk-first prioritization mindset we applied earlier to authentication posts like our WebAuthn passkey implementation guide and token protection patterns in this DPoP token replay article.

Phase 4, enforce and monitor

After the violation curve stabilized for two release cycles, I switched from report-only to enforcement for public pages. Admin remained on a looser policy to avoid plugin UX breakage while we audited backend dependencies.

Tradeoffs you should decide upfront

• Strict-dynamic vs explicit host list: strict-dynamic is cleaner for modern apps but needs confidence in bootstrap scripts.
• Inline styles: many themes need 'unsafe-inline' for CSS at first. Plan a separate cleanup sprint.
• Ad/analytics tags: some tools inject dynamic scripts unpredictably. Decide what business signals are essential before locking policy.
• Admin vs frontend: enforcing same policy everywhere can break editors and plugin dashboards. Segment policies if needed.

Troubleshooting: what broke for me and how I fixed it

1) “Refused to execute inline script” on homepage

Cause: theme had inline bootstrapping JavaScript without nonce.
Fix: moved script to enqueued file or injected matching nonce for unavoidable inline block.

2) Random failures after enabling full-page cache

Cause: cached HTML nonce did not match new response header nonce.
Fix: bypass cache for nonce-bearing pages, or render nonce at edge consistently in both HTML and header.

3) Third-party widget disappeared in production only

Cause: widget loaded nested script chain from unaccounted origin and violated script-src / connect-src.
Fix: captured violation sample, validated vendor need, then allowed only required endpoints, not wildcard domains.

FAQ

Q1: Is CSP enough to stop all XSS on WordPress?

No. CSP reduces exploitability, especially script execution paths, but vulnerable code is still vulnerable. Keep sanitization, escaping, and plugin hygiene in place.

Q2: Should I start with enforce mode directly?

Usually no. Start with Content-Security-Policy-Report-Only, fix high-volume violations, then enforce gradually. Direct enforcement often causes avoidable outages.

Q3: Nonce or hash for WordPress, which is better?

For server-rendered WordPress, nonces are usually operationally easier. Hashes are excellent for static assets and stable inline snippets, but become brittle when markup changes frequently.

Actionable takeaways

• Ship report-only CSP this week and collect 7 days of violation data before enforcing.
• Implement a per-response cryptographic nonce and apply it to all enqueued script tags.
• Separate frontend and admin CSP policies during migration to avoid unnecessary editor downtime.
• Fix inline handlers and stale script dependencies, then enforce on high-traffic public pages first.
• Review violation trends every release, because new plugins can silently weaken your browser security posture.

Sources reviewed

• MDN, Content-Security-Policy header reference
• web.dev, Mitigate XSS with a strict CSP
• OWASP, Content Security Policy Cheat Sheet
• WordPress Developer Docs, script_loader_tag hook

If you already hardened server and login flows but still trust every script by default, CSP is the missing browser-side boundary. Roll it out carefully, but roll it out.