fepo CSP & Security Headers

A Content-Security-Policy (CSP) tells browsers which sources a page may load scripts, styles, fonts, images and frames from. Writing one by hand for a WordPress site with a theme, a page builder, a shop and a cookie banner is tedious and error-prone. This plugin does the legwork for you.

How it works

1. Click “Start scan”. Your browser opens every page of your site in a hidden frame — the home page, shop pages, the newest entry of each post type and the rest of your content (up to 500 pages).
2. For each page the scan records which external sources it loads and which inline scripts and styles it contains.
3. From all pages together the plugin builds one policy. Inline code is allowed by hash when it is stable; when it changes per visitor (for example because it carries a WordPress nonce) or uses inline event handlers, the policy falls back to 'unsafe-inline' instead of breaking your pages.
4. The policy is sent as a Report-Only header first. Browsers report what the policy would have blocked, nothing is actually blocked. Reported sources show up on the “Reports” tab and can be added to the policy with one click.
5. The plugin remembers which sources each page needs. The “Pages” tab shows when a page was last scanned and whether it changed since. Rescan a single page, or all changed and new pages at once, instead of the whole site.
6. Once no new reports come in, switch the mode to Enforce on the “Policy” tab. Browsers then block everything the policy does not allow.

What you get

• Content-Security-Policy in Report-Only or Enforce mode, sent as an HTTP header (never as a meta tag). Enforce warns you while reported sources are still missing from the policy.
• Reports endpoint on your own site (/wp-json/fepo-csp/v1/report), stored without IP address or user agent and deleted after 30 days.
• Further security headers: X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options and, if you confirm your site runs on HTTPS only, Strict-Transport-Security in two stages.
• Headers that your server already sends are detected and not sent a second time.
• On Apache and LiteSpeed Enterprise the headers can be written into a marked block of your .htaccess; the plugin then checks that they really arrive and removes the block again if your server ignores it. For nginx, OpenLiteSpeed, Caddy and IIS you get the matching configuration text to copy.
• WooCommerce: optionally puts one product into your own cart so the checkout can be scanned too (removed afterwards), and adds the documented sources of active payment providers (Stripe, WooPayments, PayPal, Mollie, Klarna, Adyen).
• Clicks “Accept” on common cookie banners during the scan, so that trackers loaded after consent are part of the policy.
• “Pages” tab: every scanned page with its last scan time and status — up to date, changed since the last scan, or not scanned yet (for example a new post).
• Rescan one page with its “Rescan” button, or all changed and new pages with “Rescan all changed and new pages” (up to 50 per run).
• Unused sources: when no scanned page needs a source any more (for example after you deleted the post with a video embed), the “Policy” tab lists it with a “Remove” button. Nothing is removed automatically.
• Deleted or unpublished posts leave the page list by themselves.

Privacy

The plugin itself sends no data to fepo or to any third party.

• The scan runs in your logged-in admin browser and opens your pages the way a visitor would. Everything embedded in those pages loads as usual — including third-party services and trackers, and also those that only load after the “Accept” click on your cookie banner, which the scan performs. These services receive the usual request data from your browser, just as on a normal visit.
• While a scan runs, its page views can therefore show up in your statistics (for example in an analytics tool), and the “Accept” click may change your own consent choice in this browser.
• To find out which headers your server already sends, the plugin requests your own home page from your server (when activated, from the plugin page, after a scan and once a day). After writing to .htaccess it also requests your home page and wp-admin once to make sure the server still answers, and your home page up to three more times to make sure the headers arrive.
• The page list is stored in your own database: the page address, the sources and inline-code hashes the page needs, the time of the scan and the last-modified date of the post — no visitor data.
• Browser reports go to your own site. They are only accepted while the plugin’s policy is active and only for pages of your own site. The plugin stores the directive, the origin of the blocked source, the path of the page, a counter and two timestamps — no IP address, no user agent, no cookies — and deletes them after 30 days.
• The plugin sets no cookies of its own and loads no external scripts, fonts or images.

External services

This plugin does not connect to any external service. It sends no data to fepo or to any third party.

• The only requests the plugin makes go to your own site: it requests your own home page (and wp-admin after writing to .htaccess) to see which headers your server sends. See “Privacy” above.
• The WooCommerce payment providers (Stripe, WooPayments, PayPal, Mollie, Klarna, Adyen) are not contacted by the plugin. Their documented domains are only written into your Content-Security-Policy as allowed sources, so that your checkout keeps working when the policy is active. The links in data/payment-providers.php point to the providers’ public CSP documentation they were taken from.