CSP Header Generator Overview

The CSP Header Generator provides a visual interface for constructing strict Content Security Policy (CSP) rulesets. Operating entirely on the client side using an Alpine.js framework, it translates toggled inputs and custom domains into a properly formatted HTTP response header string. This tool removes the need for manual string concatenation, preventing syntax errors like missing semicolons or incorrectly quoted keywords.

How the Policy Engine Evaluates Rules

The generator maintains an internal state object encompassing 13 distinct CSP directives. As you toggle checkboxes or enter custom domains, the Alpine.js reactivity engine recalculates the final output string in real-time (once the policy is initially generated).

When parsing a specific directive:

• The 'none' Override: If the 'none' checkbox is activated, the engine automatically clears all other inputs (like 'self', 'unsafe-inline', and custom domains) for that directive and outputs strictly 'none'.
• Keyword Quoting: The tool automatically applies the required single quotes to reserved CSP keywords. For example, selecting "self" correctly outputs 'self' rather than just self, which browsers would incorrectly interpret as a literal host named "self".
• Custom Domain Parsing: The custom domains input accepts either space-separated or comma-separated values. The tool uses a regular expression (split(/[\s,]+/)) to parse this string, filtering out empty entries before appending them to the directive's source array.

Supported Directives and Constraints

Not all CSP keywords are applicable to every directive. The tool programmatically restricts which checkboxes are available based on the current directive context using conditional template rendering:

• 'unsafe-inline': Only available for default-src, script-src, and style-src. Allowing this permits the execution of inline scripts or styles.
• 'unsafe-eval': Strictly limited to default-src and script-src, permitting the use of dynamic code execution functions like eval().
• data: Allowed only for default-src, img-src, and font-src, letting you embed base64-encoded assets directly within your HTML or CSS.

Other supported directives include connect-src (for XHR, WebSockets, Fetch), object-src (which defaults to 'none' to prevent Flash/Java applets), media-src, frame-src, worker-src, base-uri, form-action, and frame-ancestors.

Advanced Global Flags

In addition to resource fetching directives, the tool supports two critical global policy flags that operate independently of specific resource types:

• Upgrade Insecure Requests: Enabled by default in the tool's initial state. This appends upgrade-insecure-requests to the policy string, instructing browsers to transparently rewrite any internal HTTP requests to HTTPS before they hit the network.
• Block All Mixed Content: When toggled, appends block-all-mixed-content. This strictly prevents loading any assets via HTTP when the host page itself is loaded over HTTPS, actively mitigating mixed-content vulnerabilities.

Worked Example: Building a Modern App Policy

Let’s construct a common policy for a modern web application that loads fonts from Google and images from an AWS S3 bucket.

Configuring the Inputs:

• default-src: Select 'self'
• script-src: Select 'self'
• style-src: Select 'self' and 'unsafe-inline' (often needed for component-based CSS frameworks)
• img-src: Select 'self' and add custom domain: https://my-bucket.s3.amazonaws.com
• font-src: Select 'self' and add custom domain: https://fonts.gstatic.com
• object-src: Select 'none'
• Global Options: Check "Upgrade Insecure Requests"

Generated Output:

default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' https://my-bucket.s3.amazonaws.com; font-src 'self' https://fonts.gstatic.com; object-src 'none'; upgrade-insecure-requests

The generator logic automatically handles all syntax requirements: joining multiple sources with spaces, separating full directives with semicolons, and accurately wrapping the 'self', 'unsafe-inline', and 'none' keywords in single quotes.

Frequently Asked Questions

How does the tool handle commas in the custom domains input?

The Alpine.js script backing the tool processes your custom domain string using the regex split(/[\s,]+/). This evaluates any combination of spaces or commas as a delimiter, meaning you can paste a comma-separated list, a space-separated list, or a messy combination of both, and the generator will accurately split them into distinct sources without breaking the CSP syntax.

Why does clicking 'none' uncheck all other options for a directive?

In the CSP specification, the 'none' keyword dictates that no URLs will match for that resource type. It is invalid to specify 'none' alongside 'self' or a custom domain. The tool’s inline event listener (@change) explicitly forces directive.self, directive.unsafeInline, and other toggles to false when 'none' is clicked, preventing you from generating a contradictory policy state.

Why can't I select 'unsafe-inline' for the img-src directive?

The 'unsafe-inline' keyword is specifically designated to allow inline <script> or <style> blocks in your document. It has no functional meaning in the context of loading images (img-src). The tool employs conditional template logic (x-if="['script-src', 'style-src', 'default-src'].includes(directive.name)") to explicitly prevent this checkbox from rendering in unsupported contexts, keeping the interface clean and preventing you from generating useless boilerplate.

What happens if I leave a directive completely unchecked and empty?

If a directive has no sources configured—meaning no checkboxes are ticked and the custom domain field is empty—the compilation script evaluates sources.length > 0 as false. As a result, the entire directive is cleanly omitted from the final generated string. The browser will then fall back to using the policy defined in default-src for that specific resource type.