Based on your screenshot, I see you are trying to add multiple CSP directives (like script-src, style-src, etc.) as separate Custom Headers.
The Solution: You actually don’t need 10 separate fields for this. The Content-Security-Policy standard is designed to be sent as a single header containing all your rules separated by semicolons (;).
How to do it correctly: Instead of splitting them, combine your rules into one long string and put it in the main “Content Security Policy” field (if available) or in one single “Custom Header” field.
This is the standard way browsers expect to receive the policy. Putting them all in one field is cleaner, more efficient, and follows the HTTP specification.
A Starter Example (Template): Here is a common policy that covers Google Analytics, Fonts, and WordPress basics. You can copy this as a starting point, but remember to adapt it to your specific plugins/services:
Browse your site. If something is blocked (like a broken image or script), you will see a red error message: “Refused to load… because it violates the Content Security Policy directive…”
Look at the domain in the error and add it to your policy string in the correct section (e.g., add https://facebook.com to script-src if a Facebook widget is blocked).
I hope this helps you build a strong policy without needing extra fields!
In fact, based on the CSP level 2 & 3 there’s a lot of more customization I can add and tailor to fit according to the attacks vectors or secure the web application.
You can have a look at the reference links I shared below.
I believe you can add ten times more custom header sections without it causing too many issues.
Right now, I’m dealing with a limitation in the custom header sections for setting up the CSP policy.
I can’t wait for you to take my suggestion onboard and enhance that additional feature.
Thank you for the detailed references. I understand you want granular control over CSP Level 2/3 directives.
Technical Clarification: I believe there is a misunderstanding about how the Content-Security-Policy header works in the HTTP standard.
You do not need multiple header fields to implement complex policies. The standard requires all directives (script-src, style-src, frame-ancestors, report-uri, etc.) to be included in a single header string, separated by semicolons (;).
Example of a complex Level 3 Policy in one field: default-src ‘none’; script-src ‘self’ ‘nonce-xyz’; style-src ‘self’ https://example.com; img-src *; media-src media1.com media2.com; frame-ancestors ‘none’; report-uri /csp-report;
You can already do this right now: In our plugin, simply use the main “Content-Security-Policy” text area (or one Custom Header field). You can paste a policy string of any length and complexity there. It supports all Level 2 and Level 3 directives perfectly.
Why we won’t add 10 separate fields: Sending multiple separate Content-Security-Policy headers (one per field) causes browsers to enforce the most restrictive intersection of all of them, which often breaks sites unintentionally and is not the standard way to deploy a policy.
Recommendation: Use a tool like Report URI’s Wizard to build your complex policy string, and then paste that single string into the plugin’s CSP field. That will give you the full power you are looking for.
Thank you so much for your detailed clarification.
Scenario 1 In that case, it would be best to remove the predetermined CSP sections (highlighted in the image below) and instead label them as a custom header.
In this way, users can decide how they want to fill it out based on their specific needs.
It might also be helpful if you can help to create a guide on how users can manage their CSP.
Scenario 2 We shall also consider avoid generating lengthy fields mainly because users can do their own testing. If we make it too long, it could be hard to troubleshoot for cases that it may just crash the whole site.
Plus, it’s easier for them to preview and make quick adjustments without having to read through a complicated and lengthy field.
Even if user have a lot of custom header sections, you might want to think about rewriting your code to combine all those sections into one single header.
Thank you for the detailed suggestions. I see what you mean about breaking down the policy for readability.
Regarding Scenario 1 (UI Labels): The plugin already provides generic “Custom Header” fields below the main ones. If you prefer not to use the dedicated CSP text area, you can simply leave it empty and use the “Custom Header” fields to define Content-Security-Policy or any other header manually.
Regarding Scenario 2 (Merging Fields): While merging multiple fields into one header programmatically is possible, it adds complexity and potential for errors (e.g., if a user wants to add a different type of header). Currently, the industry standard for managing CSP (in plugins, Cloudflare, or server configs) is a single block of text because the policy is evaluated as a whole unit.
CSP Guide: Creating a universal guide for CSP is extremely difficult because every website uses different plugins, themes, and external services (Google, Facebook, Stripe, etc.). A policy that works for Site A will break Site B. This is why we mark CSP as an “Advanced” feature. It requires the site administrator to audit their specific site’s resources using the browser console.
For now, we recommend using online tools like Report URI to build/validate your string, and then pasting the final result into our plugin.
We will keep your UX suggestion in mind for a future redesign of the headers section!
P.S. I tried to visit your site (swha.online) to check your console errors and give you a specific CSP example, but the “Right Click / Inspect Element” protection script you have installed prevented me from opening the Developer Tools. If you need further help debugging your policy, you might need to temporarily disable that protection so we (or you) can see the browser console errors that tell you exactly what is being blocked.
Lately my site has been hit by waves of difference types of cyberattacks vectors. As a result, I’ve ramped up the security on the CDN, WordPress, and web hosting.
For the most part, I’ll stick to your recommendations. I really appreciate your time and effort.
Additionally, I have another feature request on the massive blacklist import (both manually and automatically) in which I’m not sure if you’d be interested in. If so, i may just start another thread.
About your Feature Request: Please do start a new thread for that topic. It helps other users find answers and keeps the discussion focused.
Quick preview for that new thread: You can actually already export and import your Blocked IPs list!
Go to Security > Settings > Import / Export.
Choose “Export Full Backup”.
This JSON file includes your entire Blocked IPs database table. You can import this file into another site running the plugin to transfer your blocklist instantly.
If you are asking about importing external text lists (like from GitHub), that is a different story, and we can discuss the pros/cons in the new thread (spoiler: manual lists often cause false positives!).
