Security Headers Policy Generator

Configure Content-Security-Policy directives visually. Get instant security analysis and deployment-ready code for HTML, Nginx, and Apache.

⚙ Directive Configuration Builder
Directive 'self' 'none' 'unsafe-inline' 'unsafe-eval' Whitelisted Domains
🛡 Global Policy Settings
Force HTTP assets to load over HTTPS
Prevent HTTP resources on HTTPS pages
Policy Mode
Live CSP String
⚠ Security Analysis
Policy Strength
Unconfigured
Configure directives above to see your analysis.
📄 Deployment Code 

            
          

          
Note: The meta tag method does not support Content-Security-Policy-Report-Only. For Report-Only mode, use an HTTP header via Nginx or Apache.

        


        
        

          

            

            
          

          

        


        
        

          

            

            
          

          

        


      


    


    
    

    
    

      

        📚
        Key Terms Explained
      

      

        

          
Content-Security-Policy (CSP)

          
An HTTP response header that instructs browsers which content sources are trusted. It is the primary browser-level defense against cross-site scripting and data injection attacks.

        

        

          
Cross-Site Scripting (XSS)

          
An attack where malicious scripts are injected into a trusted web page and executed in the victim's browser, often stealing session cookies or redirecting users. CSP is the strongest countermeasure against XSS at the HTTP layer.

        

        

          
Nonce

          
A one-time cryptographic token generated per HTTP response and embedded in both the CSP header and specific script or style tags. The browser only executes inline code carrying the matching nonce, eliminating the need for 'unsafe-inline'.

        

        

          
unsafe-inline

          
A CSP keyword that permits inline scripts and styles written directly inside HTML. Because attackers exploit inline execution, using 'unsafe-inline' in script-src substantially weakens XSS protection and should be avoided in production.

        

        

          
Mixed Content

          
A condition where an HTTPS page loads resources (images, scripts, stylesheets) over plain HTTP. Mixed content can expose users to man-in-the-middle attacks and is blocked by modern browsers. The CSP directives block-all-mixed-content and upgrade-insecure-requests address this.

        

        

          
Report URI

          
A CSP directive that specifies an endpoint URL where browsers send JSON violation reports whenever a resource is blocked. Combined with Report-Only mode it allows you to audit a new policy without disrupting users.

        

        

          
Data URI

          
A URL scheme (data:) that encodes file content directly inside an HTML attribute or src value, such as data:image/png;base64,... . Allowing 'data:' in script-src is a security risk because attackers can use it to execute base64-encoded payloads.

        

        

          
default-src

          
The CSP fallback directive. Any fetch directive not explicitly set in the policy inherits its value from default-src. Setting it to 'self' or 'none' creates a secure baseline and limits blast radius if other directives are misconfigured.

        

      

    


    
    

      
The Complete Guide to Content-Security-Policy


      
A Content-Security-Policy header is one line of server configuration that can eliminate entire classes of web vulnerabilities. This guide explains how the policy compiles, what each directive controls, and how to roll out a new policy safely without breaking your site.


      
How CSP Directives Work

      
Every CSP consists of one or more directives separated by semicolons. A directive names a resource type and lists the sources the browser is allowed to load for that type. For example, script-src 'self' https://cdn.example.com; means: scripts may only come from the same origin or that specific CDN. Anything else is blocked silently.

      
The default-src directive acts as a catch-all fallback for any resource type that does not have its own explicit directive. Setting default-src 'none'; is the most restrictive starting point: all resource types are blocked until you explicitly open them up.


      
How to Use This Tool

      
Each row in the Directive Configuration Builder maps to one CSP directive. Check the keyword toggles that apply to your site's design, then type any external domains your pages legitimately load from. The policy string and deployment code update in real time as you make changes. Use the Security Analysis pane to catch dangerous configurations before deploying.

      
When you are ready to test in production, toggle Policy Mode to Report-Only. Deploy the generated Content-Security-Policy-Report-Only header using the Nginx or Apache output. Browse your site normally and check the browser console for violation messages. Once violations drop to zero, switch to the enforcing header.


      
The 'unsafe-inline' Problem

      
Many legacy sites rely on inline event handlers such as onclick="..." or style="..." attributes. Allowing these requires the 'unsafe-inline' keyword, which tells the browser to execute any inline code on the page, including code injected by an attacker. The recommended migration path is to move all inline JavaScript to external files and replace inline styles with CSS classes. If that is not immediately possible, a per-request nonce is the next best option: generate a cryptographically random value on the server, embed it in every trusted script tag as nonce="abc123", and add 'nonce-abc123' to your script-src. The nonce rotates every response so attackers cannot reuse it.


      
Frequently Asked Questions


      

        
        

          A Content-Security-Policy header tells the browser which sources of scripts, styles, and media are trusted. Even if an attacker injects a malicious script into your page, the browser refuses to execute it if it does not originate from an approved source. No other single HTTP header has the same capacity to neutralize cross-site scripting at the browser level.
        

      


      

        
        

          The browser will silently block the script and log a violation to the browser console. The affected feature simply stops working. This is why testing in Report-Only mode first is strongly recommended: the policy is evaluated and violations are logged, but nothing is actually blocked, so you can identify gaps without breaking your site.
        

      


      

        
        

          Toggle the Policy Mode to Report-Only using this tool. The generated header changes to Content-Security-Policy-Report-Only. Deploy it alongside your existing policy. The browser reports all violations without enforcing blocks. Once your violation log shows zero unexpected issues, switch the header to the enforcing version.
        

      


      

        
        

          Inline scripts (written directly inside HTML with script tags or event handlers like onclick) cannot be distinguished from injected attacker scripts by the browser. Allowing 'unsafe-inline' in script-src means any injected code, whether from a comment field, a stored XSS payload, or a third-party widget, will execute with full page privileges. The recommended alternative is to load all scripts from external files on whitelisted origins, or use a per-request nonce.
        

      


      

        
        

          Both headers use identical directive syntax. The enforcing header (Content-Security-Policy) blocks any resource that violates the policy. The Report-Only header logs violations to the browser console and to a report-uri endpoint if configured, but does not block anything. Report-Only is the standard way to audit a new policy before enforcement.