BoundaryGuard Headers

No. BoundaryGuard Headers uses PHP headers, which improves compatibility across different hosting environments.

Yes. The plugin includes a CSP Report-Only Mode that allows you to monitor policy violations without blocking any resources.

No. The plugin is lightweight and adds negligible overhead, as headers are sent as part of the normal HTTP response.

It’s a 0-100 score (A+ to F) shown on the Dashboard, based on nine weighted checks across all four header groups. Full breakdown of point values is on the in-plugin Documentation page.

It checks your site’s actual live response headers, not just this plugin’s own settings — so if a header is already being sent by your host, theme, another plugin, or a CDN, you get credit for it and it’s labeled “External” so you always know where the protection is really coming from.

It depends on how caching is set up. Headers are sent through PHP on each request, so they apply whenever WordPress actually handles that request. If a full-page cache serves a stored HTML file directly (bypassing PHP entirely) or a CDN edge serves from its own cache, this plugin’s headers won’t be part of that cached response. Run the Live Header Scan after setting up caching to confirm the headers are still showing up on the live site — if they’re missing, you may need your caching layer to pass through origin response headers, or add matching headers at the server/CDN level as a supplement.

Nonce Mode replaces the looser 'unsafe-inline' / 'unsafe-eval' allowance on script-src with a unique per-request nonce, which is a meaningfully stronger policy. It only helps your inline <script> tags if they carry that nonce, though — use the BoundaryGuard_Headers::nonce_attr() helper (see the in-plugin Documentation page) to add it to any inline scripts your theme or plugins output. Turn it on after adapting your inline scripts; otherwise, unnonced inline scripts will be blocked once CSP is enforced.

Switch to CSP Report-Only Mode — it logs what the policy would have blocked without actually blocking anything. Check the Violation Log to see exactly which sources are being flagged, add the legitimate ones to the CSP Builder (presets cover common services like Google Analytics, Stripe, YouTube, etc., or add custom domains), then switch back to enforcing mode once the log is clean.

When “Log Violations” is enabled, visitors’ browsers report anything your Content Security Policy blocks (or would block, in Report-Only Mode) to a REST endpoint this plugin registers, and that report is stored in your own database — no third-party service is involved. The Violation Log page shows a 14-day trend, your top blocked sources, and a breakdown by directive, with CSV export and a one-click “Clear Log” (with a confirmation prompt) if you want to start fresh.

Only enable HSTS once your site is reliably served over HTTPS with a valid SSL certificate. HSTS tells browsers to refuse plain-HTTP connections to your domain for the duration you set (one year by default) — if your certificate lapses or you need to fall back to HTTP, visitors won’t be able to reach the site until the max-age expires or they manually clear HSTS in their browser.

Yes. Use “Export Settings (.json)” on the Import/Export page, then upload that file on the destination site’s Import/Export page. Useful for agencies applying the same policy across multiple client sites.

Deactivating asks whether to keep or delete your settings and violation log. Deleting the plugin afterward always removes both via uninstall.php , including on multisite.