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.

Apache may receive plain HTTP from an HTTPS-terminating proxy. The generated .htaccess rules accept either Apache HTTPS or X-Forwarded-Proto: https for these HTTPS-only headers. Configure the trusted proxy to overwrite X-Forwarded-Proto on every request, rather than passing through a client-supplied value. After updating, save the plugin settings to regenerate .htaccess, purge hosting and CDN caches, and test an HTTPS page and an HTTP request. WordPress-generated responses also depend on WordPress is_ssl() recognizing the proxy; configure that separately if the diagnostics screen reports HTTPS as No. If Nginx or a CDN serves the response without Apache, add the headers at that layer.

In Security Headers settings, uncheck "Send reports to the built-in collector" and clear any custom report-uri value, then save and purge page/hosting/CDN caches. This removes report destinations from newly served CSP policies without disabling the CSP policy itself. The collector returns HTTP 204 without storing reports while disabled. Browsers that received an older policy may continue posting for a while, and every report request that reaches WordPress still starts PHP. During a server overload, ask the host to short-circuit POST requests to /wp-json/firstpage-sg-security-headers/v1/csp-report at Nginx or its edge firewall so they do not reach PHP. Verify that normal site pages and other REST routes remain available.