fepo CSP & Security Headers

FAQ

Do I have to keep the tab open during the scan?

Yes. The scan runs in the browser tab where you started it. It keeps running while the tab is in the background, so you can work in another tab. If you close or reload the tab, the plugin page offers “Continue scan” and picks up where it stopped.

I use a page cache. What do I need to know?

Cached pages may keep the headers they were stored with. Clear the cache after a scan and after changing headers. The plugin shows a hint when it detects a known cache plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround Optimizer, Cloudflare).

My server or another plugin already sends a Content-Security-Policy.

Then this plugin does not send its own policy, because browsers apply both policies and the stricter result can break your site. Remove the other header first; the “Policy” tab shows a warning as long as it is present. Other security headers that already exist are left alone in the same way.

Will the policy break my site?

Not in Report-Only mode: nothing is blocked, browsers only report. The plugin never switches to Enforce by itself, and a new scan does not change the mode once you chose Enforce. Switch to Enforce on the “Policy” tab when the “Reports” tab stays quiet; if something stops working, switch back to Report-Only and add the reported source.

Why are no security headers sent right after activation?

Nothing changes on your site until you decide: the security headers stay off until you save the “Headers” tab or a scan finishes. The scan then switches on X-Content-Type-Options, Referrer-Policy and — if your server does not send it already — X-Frame-Options. Permissions-Policy stays off unless you switch it on, because it disables camera, microphone and location for your pages. If the plugin page says “Headers are not sent yet”, your server could not load its own home page; the notice lists common causes.

Why don’t I see the Content-Security-Policy header when I am logged in?

When the plugin sends the headers itself, logged-in users do not get the policy: the admin bar and the block editor load their own inline code, which would otherwise fill the reports. Log out or use a private window to check the header. Headers sent by your web server behave differently: the .htaccess block (Apache, LiteSpeed Enterprise) and the configuration text for nginx, OpenLiteSpeed, Caddy and IIS reach every visitor, logged in or not, but they keep the policy away from wp-admin and the login page.

My web server is nginx, OpenLiteSpeed, Caddy or IIS. What is different?

Nothing you have to do: the plugin sends all headers itself through WordPress, on any web server. The configuration text on the “Policy” tab is optional; with it, your web server sends the headers instead, also for files that WordPress does not deliver. Like the .htaccess block, the text sends the policy everywhere except wp-admin and the login page. If you use it, keep two things in mind. The plugin cannot change your server configuration, so copy the updated text again after a new scan or after adding a source from the “Reports” tab. As soon as your server sends a Content-Security-Policy, the plugin stops sending its own (click “Re-check headers” after changing the server). On nginx, also copy the lines into every location block that has add_header lines of its own, because nginx does not pass them on there.

Why does my policy contain ‘unsafe-eval’?

Pages with WordPress JavaScript templates (wp.template), for example WooCommerce variable products, compile those templates at runtime. That needs 'unsafe-eval' in script-src, so the scan adds it when it finds such templates.

Why does my policy contain ‘unsafe-inline’?

Many WordPress plugins print inline scripts that contain a nonce. Nonces change for every visitor and at least once a day, so a hash of such a script would be wrong for the next visitor. In that case, and when pages use inline event handlers such as onload="…", the policy allows inline code instead of listing hashes. Style attributes (style="…") have the same effect on style-src. With more than 30 different inline scripts or styles the header would get too long, so the policy uses 'unsafe-inline' there as well and the “Policy” tab says so.

Do I have to run a full scan after every change?

No. The “Pages” tab marks posts that were edited after their last scan as “Changed since last scan” and new posts as “Not scanned yet”. Use the “Rescan” button of a page or “Rescan all changed and new pages”. A full scan from the “Scan” tab is still useful after you changed your theme or a plugin that affects every page.

Why is a source listed as unused, and why is it still in my policy?

A source is unused when no scanned page loads it any more, for example after you removed an embedded video. The plugin never removes sources by itself, because a page that was skipped during a scan or a page you did not rescan may still need it. Check the list and click “Remove” for the sources you no longer need. Sources of active payment providers and sources you added from the “Reports” tab are never listed as unused.

Why is my admin area or front page address important?

The scan opens your pages in a frame of the admin page. Browsers only allow that when both use the same protocol, host and port. If they differ, the scan is not offered.

Does it work on a multisite network?

Yes. Each site has its own scan, policy and settings, and the plugin sends the headers for each site itself, on any web server. Only the optional .htaccess block is shared: on Apache and LiteSpeed Enterprise all sites use one .htaccess file, so only a super admin can write the headers there; site admins get the text to copy instead. On nginx, OpenLiteSpeed, Caddy and IIS the plugin never writes server files; you get the configuration text to copy.

What happens when I deactivate or delete the plugin?

Deactivating stops all headers the plugin sends and removes its block from your .htaccess (Apache, LiteSpeed Enterprise). Configuration text you copied into nginx, OpenLiteSpeed, Caddy or IIS stays in your server configuration until you remove it yourself. Deleting the plugin also removes its tables, options and the per-user settings it stored, on every site of a multisite network. If your .htaccess is no longer writable, the plugin cannot remove its block; the plugin page and the Plugins screen then tell you which lines to delete by hand.