What is CSP Parser?

A tool that parses Content Security Policy (CSP) headers and displays each directive in an easy-to-understand format. It visualizes complex security configurations and automatically diagnoses potential issues.

When you need to check your website's security settings, simply paste the CSP header from your browser's developer tools into this tool to instantly verify the configuration.

Quick Diagnosis Feature

When you input a CSP, the tool performs basic pattern-matching checks. It detects common issues such as the following.

• Use of 'unsafe-inline' or 'unsafe-eval' - Dangerous settings that increase XSS attack risk
• Use of wildcards (*) - Allowing all domains
• Missing default-src - No fallback configuration
• Use of HTTP - Allowing unencrypted communication

Diagnostic results are displayed with severity levels (HIGH/MEDIUM/LOW), but this is only a basic check. Comprehensive security assessments require professional audits.

CSP Basics

Content Security Policy (CSP) is an HTTP response header that prevents XSS attacks and data injection attacks. It enhances website security by restricting the types and sources of resources that browsers can load.

Common Directives

Fetch Directives

• default-src - Default setting for all resource types
• script-src - JavaScript file sources
• style-src - CSS file sources
• img-src - Image sources
• connect-src - fetch, XMLHttpRequest, WebSocket connection destinations
• font-src - Web font sources
• media-src - Video and audio file sources
• frame-src - Pages that can be embedded in iframes

Document Directives

• base-uri - URLs that can be specified in <base> tag
• sandbox - Restrictions similar to iframe sandbox attribute

Navigation Directives

• form-action - Form submission destinations
• frame-ancestors - Pages that can embed this page (clickjacking protection)

Source Specification Types

• 'self': Only allows resources from the same origin (domain)
• 'none': Prohibits all resources
• 'unsafe-inline': Allows inline scripts and styles (security risk)
• 'unsafe-eval': Allows dynamic code execution like eval() (security risk)
• https:: Allows all resources via HTTPS
• data:: Allows resources using the data: scheme
• Specific domains: Explicitly permitted domains like https://example.com

Key Features

Categorized Display

Directives are organized into four categories: Fetch, Document, Navigation, and Reporting. This grouping makes it easier to understand the overall configuration and review related settings together.

Color-coded Badges

Each source value is color-coded.

• Red (Dangerous) - High security risk settings like 'unsafe-inline' and 'unsafe-eval'
• Yellow (Warning) - Settings requiring caution like data: and blob:
• Blue (Keywords) - CSP reserved words like 'self' and 'none'
• Green (Domain) - Trusted hosts like https://example.com
• Gray (Other) - Regular strings

Privacy Protection

All processing happens in your browser. Your CSP configurations are never sent to external servers.

How to Use

Getting CSP from Browser

You can check CSP using developer tools in Chrome/Edge/Firefox.

1. Open developer tools with F12
2. Go to the Network tab
3. Reload the page
4. Click the first document (usually at the top)
5. Look for content-security-policy in the Headers tab

Parsing and Diagnosis

Paste the CSP header into the text area and parsing begins automatically.

default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.example.com

Immediately after input, the following information is displayed.

• Quick Diagnosis - Security issues classified by severity (HIGH/MEDIUM/LOW)
• Policy Breakdown - Directives organized by category
• Color-coded Badges - Safety level of each source value

Understanding Results

In this example, style-src 'unsafe-inline' appears as a warning. Allowing inline styles increases XSS attack risk.

When to Use This Tool

Launching a New Site

When setting up CSP for the first time, verify that your syntax is correct and restrictions match your intentions. Use it as a pre-deployment checklist.

Resolving CSP Violations

When you see "Content Security Policy violation" in the browser console, visualize your current configuration to identify which directive is causing the issue.

Security Audits

When reviewing existing site CSP settings, check for dangerous configurations like 'unsafe-inline' or 'unsafe-eval' at once.

Adding External Scripts

When adding scripts from Google Analytics or CDNs, organize which directives need which additions.

Tips for Safer CSP Configuration

Remove 'unsafe-inline'

Avoid inline scripts and styles by moving them to external files, eliminating the need for 'unsafe-inline'. If absolutely necessary, consider using nonce or hash-based allowlisting.

Avoid Wildcards

Subdomain wildcards like https://*.example.com are risky if an attacker can control any subdomain. List specific subdomains individually for better security.

Set object-src to 'none'

If you're not using plugin content, explicitly specify object-src 'none'. By default, it's not restricted, so this prevents vulnerabilities from configuration oversights.

Test with Report-Only Mode

Before applying a new CSP, test with the Content-Security-Policy-Report-Only header for 1-2 weeks. Collect CSP violation reports from real user environments, and only move to production after confirming there are no issues.