Security Headers

New installs enable a minimal enforced Content-Security-Policy: upgrade-insecure-requests on HTTPS responses. It upgrades HTTP resource URLs to HTTPS without adding script or other source restrictions. Resources unavailable over HTTPS will fail to load. You can disable it using the HTTPS resource upgrades checkbox. Existing installations keep their previous behaviour and must opt in to HTTPS resource upgrades after updating. Advanced CSP remains disabled by default because source restrictions need website-specific configuration.

Yes, for advanced CSP. Report-Only mode reports advanced policy issues without blocking resources. The separate HTTPS resource upgrades setting remains enforced even while advanced CSP is in Report-Only mode. When advanced CSP is enforced, the baseline directive is merged into that policy.

No. A grade depends on the headers actually returned for each scanned URL and the scanner's criteria. The minimal upgrade policy does not restrict script sources or provide the XSS protection of a carefully configured CSP.

1. Open Security Headers > Discover / Review / Enforce and acknowledge Start / Resume Discovery. On first use, this saves a settings backup and replaces advanced CSP with a same-origin Report-Only starter. This does not block advanced policy violations; the separate HTTPS upgrade baseline remains enforced if enabled.
2. Purge page, hosting, and CDN caches. Browse important pages and exercise forms, booking, chat, lazy loading, analytics, login roles, and consent states. HTML detection suggests scripts, styles, images, fonts, frames, media, and manifests. Browser reports provide additional origins for dynamic requests, CSS dependencies, APIs, and workers. The plugin does not fetch external JS/CSS files or execute JavaScript to crawl the site.
3. Review suggestions. Approve recognised required origins or reject unwanted suggestions. Unsafe inline/eval and broad data/blob script permissions require a separate risk acknowledgment; manually configured hashes/nonces can be preferable. Discovery never automatically includes sources in the policy. Existing manual CSP fields remain explicit configured permissions, so rejecting a suggestion does not override them.
4. Verify the public Report-Only policy for a same-site page path. The tool does not add cache-busting parameters or follow redirects. It requires HTTP 200 HTML with the matching policy. This confirms one response, not full site coverage. Approvals and policy changes invalidate verification.
5. With no pending suggestions, confirm browser testing and cached-page header coverage, then use Enforce Reviewed Policy. The fixed policy contains approved origins plus manual fields; it never expands based on HTML or public reports. Purge caches again and verify the enforced policy. Resume Report-Only testing before changing approvals.

No. Detection is a compatibility aid, not a security audit. Public browser reports can be forged and are never treated as trusted approvals. The plugin may miss features not exercised, conditional requests, logged-in variations, and reports that do not arrive. Missing reports do not prove safety. Origin approvals permit more than a single file, and broad permissions in manual fields can weaken CSP. Discovery is capped at 250 source/directive pairs; reports are limited to 16 KB, 20 entries per batch, and 60 entries per client per minute. Limits can prevent complete observations. New installs use the reviewed-source workflow and disable automatic source inclusion. Existing installations keep legacy settings until an administrator explicitly starts discovery. Legacy automatic inclusion can also permit attacker-injected sources and is retained only for compatibility.

In bounded WordPress options on your own site, not in an external service unless you configure an external report endpoint. Page paths are stored without visitor query strings or fragments. Reports and source suggestions are untrusted. Removing the plugin through WordPress uninstall deletes its settings, reports, discovery, verification, and workflow backup options.

Page caches, hosting proxies, and CDNs can serve HTML without running WordPress. PHP headers cannot cover those responses. Apache rules can cover static cache files when Apache processes the plugin's generated .htaccess rules, but Nginx does not read .htaccess. Ask your host to apply security headers at the cache-serving layer and avoid duplicate headers. Purging caches alone may not solve the issue if the cache bypasses WordPress again. Auto-detected advanced CSP requires WordPress to inspect rendered HTML. It cannot detect sources in a static cache response. Emergency CSP bypass also requires a WordPress-generated response and cannot bypass policies enforced by your server or CDN.

No. HSTS should only be enabled when your site is fully available over HTTPS.