Visual CSP Header Builder & Auditor

1Understanding CSP Architecture

Beyond the basic definition, CSP provides a standard method for website owners to declare a rigorous defense-in-depth security posture. By specifying a whitelist of permitted domains, a CSP essentially neutralizes XSS payloads, even if a vulnerability exists in the underlying application code.

2How to Use the Visual CSP Builder

Writing CSP headers manually is prone to syntax errors that can completely break modern web applications. The Visual CSP Header Builder solves this by providing a deterministic, GUI-driven construction environment.

3Anatomy of CSP Directives

A CSP is composed of one or more directives, separated by semicolons. Each directive governs a specific type of resource fetching or execution context within the browser document.

The most critical fetch directive is script-src, which restricts where JavaScript can be loaded from and how it can be executed. Other vital directives include style-src (CSS), img-src (images), and connect-src (XHR/Fetch/WebSockets).

4Default-Src vs. Specific Directives

The default-src directive serves as a fallback for the majority of fetch directives. If a specific directive (like font-src) is completely omitted from the policy, the browser will enforce the rules defined in default-src for that resource type.

Crucial exception: default-src does not act as a fallback for all directives. Directives like frame-ancestors, report-uri, and sandbox are entirely unaffected by default-src and will default to allowing everything if omitted.

5The Dangers of 'unsafe-inline' & 'unsafe-eval'

Many developers, frustrated by CSP breaking their legacy applications, resort to adding 'unsafe-inline' to their script-src. This is a critical security failure.

'unsafe-inline' allows the execution of inline <script> blocks and inline event handlers (like onclick). Since almost all XSS vulnerabilities rely on injecting inline scripts, authorizing 'unsafe-inline' effectively neutralizes the primary protection CSP offers.

Similarly, 'unsafe-eval' permits the use of eval() and related string-to-code APIs. While less dangerous than inline scripts, it still provides an execution vector for attackers who can manipulate string inputs.

6Implementing Nonce-Based Strict CSP

To secure inline scripts without using 'unsafe-inline', the modern web relies on Nonces (Number Used Once). A nonce is a cryptographically strong, base64-encoded random string generated dynamically on the server for every single page load.

The server injects this nonce into the CSP header:
Content-Security-Policy: script-src 'nonce-rAnd0m123' 'strict-dynamic';

And matches it on the authorized inline scripts:
<script nonce="rAnd0m123">...</script>

Because an attacker injecting a malicious script cannot predict the randomly generated nonce for that specific HTTP response, the browser will refuse to execute the injected payload.

7Hash-Based CSP for Static SPAs

Single Page Applications (SPAs) deployed via static CDNs (like Vercel or Netlify) often cannot generate dynamic nonces on a per-request basis. In these scenarios, Hashes provide the alternative.

By computing the SHA-256 (or SHA-384/512) hash of the exact inline script content, developers can authorize that specific code block within the header:

Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8=';

If an attacker injects a script, its hash will inevitably differ, and the browser will block it. This ensures pristine integrity for statically compiled frontend assets.

8CSP Reporting: report-uri vs report-to

Deploying a strict CSP on a legacy application can cause massive breakage. To mitigate this, CSP offers a Report-Only mode via the Content-Security-Policy-Report-Only header. In this mode, the browser will not block resources; it will only simulate the blocks and send JSON violation reports to a specified endpoint.

9Defeating Clickjacking with frame-ancestors

Clickjacking occurs when an attacker embeds your site within a transparent <iframe> on a malicious domain, tricking users into clicking buttons they didn't intend to. The legacy defense was the X-Frame-Options header.

The CSP frame-ancestors directive supersedes X-Frame-Options. It allows you to explicitly declare exactly which parent origins are allowed to embed your application.

Content-Security-Policy: frame-ancestors 'self' https://partner.com;

If you do not want your site embedded anywhere, ever, use frame-ancestors 'none';.

10HTTP Header vs. HTML Meta Tag CSP

While CSP is primarily delivered via HTTP response headers, it can also be delivered directly within the HTML document using a `` tag. This is useful for static sites where developers lack access to the web server configuration.

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Limitations: Meta tag CSPs cannot use reporting directives (report-uri, report-to), framing directives (frame-ancestors), or the sandbox directive. For complete security, HTTP headers are strictly required.

11Technical Glossary

12CSP for WordPress: A Complete Guide

WordPress is the most widely targeted CMS for XSS attacks due to its plugin ecosystem. A correctly configured CSP is the single most impactful server-hardening step you can take for any WordPress site.

The best practice is to generate a per-request nonce in functions.php and use the wp_script_attributes filter to inject it into all enqueued scripts automatically:

Then inject the CSP header via the send_headers action hook, including your generated nonce:

13CSP for Next.js, React & SPAs

Single Page Applications built with Next.js or Create React App inject significant amounts of inline script, including runtime chunk bootstrapping. The recommended approach differs significantly depending on whether you use the Next.js App Router or the older Pages Router.

14Common CSP Bypass Techniques & Mistakes

Even a well-intentioned CSP can be completely bypassed if common mistakes are made. The following techniques are used by attackers to circumvent poorly configured policies — and are exactly what the Attack Surface Analyzer tool above detects.

15Complete CSP Directive Reference (All 25)

The full CSP Level 3 specification defines 25 distinct directives across four categories. This is the most comprehensive reference for developers needing to understand every possible configuration option.

16Nginx & Apache: Production Configuration Patterns

The correct syntax for deploying a CSP header differs between Nginx and Apache. Both must be configured at the server or virtual host level for the header to apply to all responses, including static assets.

17CSP Browser Support Matrix (2026)

CSP Level 3 is supported by all modern browsers as of 2026. However, some newer directives and keywords have varying support levels that developers must account for, especially when supporting older enterprise environments running Internet Explorer 11.

IE 11 Compatibility: If you must support IE 11, include both X-Content-Security-Policy (Firefox 3.x/IE10 prefixed header) alongside the standard CSP header. However, IE 11 will only enforce a very limited subset.

18CSP vs. Other HTTP Security Headers

CSP is a powerful tool but works best as part of a complete HTTP security header stack. Here is how CSP relates to and complements (or supersedes) other security headers:

FAQFrequently Asked Questions

~. Explore More Utility Tools