CSP Validator

Content Security Policy (CSP) is a security standard that prevents unauthorized script execution and other malicious content from running on web pages. It works by having web servers specify which sources (domains, scripts, stylesheets, images, etc.) are allowed to load on a page. The browser then enforces these restrictions, blocking any resources from unauthorized sources.

The Problem It Solves: Cross-Site Scripting (XSS) attacks are among the most common web vulnerabilities, where attackers inject malicious JavaScript into web pages. Traditional defenses (input validation, output encoding) have limitations—encoding can be bypassed, and developers sometimes miss encoding opportunities. CSP provides a second line of defense by preventing inline scripts and restricting script execution regardless of how the content arrived on the page.

CSP addresses multiple attack vectors: Inline Script Attacks where attackers inject <script> tags, External Script Injection where attackers load malicious scripts from external sites, Eval and Dynamic Code where attackers execute dynamic JavaScript, and Event Handler Injection where attackers inject event handlers like onerror=alert(). A properly configured CSP blocks all these attack methods, making XSS exploitation extremely difficult.

CSP works through directives—configuration rules that specify what's allowed. Each directive controls a specific resource type. script-src controls JavaScript source restrictions and is the most critical. Setting script-src 'self' allows only scripts from your own domain, blocking injected inline scripts and external malicious scripts.

Key Directives: default-src 'self' provides a baseline restriction for all resource types. style-src controls stylesheets (prevents CSS injection attacks). img-src controls images. connect-src controls fetch/XHR requests (prevents data exfiltration to attacker-controlled servers). font-src controls fonts. frame-src controls iframes.

Advanced Directives: script-src-elem and script-src-attr allow fine-grained script control—distinguish between scripts loaded via <script> tags and event handler attributes. unsafe-inline allows inline scripts/styles but should be avoided. unsafe-eval allows eval() and related functions but introduces serious vulnerabilities. nonce and hash allow specific inline scripts by cryptographic verification—the server generates a random nonce or SHA hash, includes it in the script tag, and CSP header references it. Only scripts matching the nonce/hash execute.

Practical Example: A basic strong CSP might be: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' fonts.googleapis.com; img-src 'self' data: https:; connect-src 'self'. This allows scripts from your domain and a trusted CDN, styles from your domain and Google Fonts, images from your domain or data URIs, and fetch requests only to your domain.

The main CSP implementation challenge is incompatibility with existing code. Inline Scripts: Many older websites embed JavaScript directly in HTML rather than in external files. These fail under strict CSP because inline scripts are blocked by default. Migration requires extracting all JavaScript to external files.

Third-Party Scripts: Many websites depend on third-party services: analytics (Google Analytics), advertising (Google Ads), payment processors, chat widgets, etc. Each requires CSP exceptions, expanding the policy and increasing attack surface. If a third-party service is compromised, CSP no longer protects you. Solution: Only whitelist absolutely necessary third-party services, regularly audit them for necessity, and consider self-hosting analytics or critical services.

jQuery and Legacy Frameworks: jQuery and older JavaScript frameworks sometimes use eval() or inline event handlers, conflicting with strict CSP. Migration to modern frameworks, or updating to newer jQuery versions that support CSP, becomes necessary. Additionally, many build tools (Webpack, Parcel) can automatically extract inline styles to external files if configured correctly.

Report-Only Mode: Implement CSP in report-only mode initially (Content-Security-Policy-Report-Only header). This doesn't block violations but reports them to a specified endpoint. Monitor reports for 1-2 weeks to identify legitimate violations, then switch to enforce mode. This gradual migration prevents breaking your application while protecting against future attacks.

Nonce-Based Approaches: For inline scripts you can't easily remove, use nonces. Generate a random nonce server-side for each page load, include it in inline script tags, and reference it in the CSP header. While not perfect (nonces can be leaked if attacker can read page source), nonces work well for template-based architectures.

Automated CSP Parsing and Validation: Use CSP validators to check policy syntax and warn about weak configurations. Mozilla's CSP evaluator and similar tools scan your CSP header and flag potential issues: overly permissive directives, use of unsafe-inline, missing directives, and ineffective configurations.

Testing Methodology: Use automated security scanning tools (Burp Suite, OWASP ZAP) to verify CSP enforcement. These tools inject various XSS payloads and verify they're blocked by CSP. Manual testing involves attempting common XSS attacks: inline script injection, eval() calls, unsafe event handlers, and external script loading from unauthorized sources. Each attempt should be blocked and reported.

Report Monitoring: CSP can be configured to report violations to a logging endpoint. Implement report collection and monitoring to detect both real attacks (external users attempting XSS) and implementation issues (legitimate resources blocked by your policy). Analyze reports for patterns: sudden spikes might indicate attack attempts, while gradually increasing reports might indicate third-party service changes.

Regular Audits: Review CSP policies quarterly to verify they still make sense. Security requirements change as you add new features or third-party integrations. Additionally, monitor security advisories for third-party services listed in your CSP—if a service experiences a security incident, you might need to remove it or update your CSP.

Incident Response: Define how to respond to CSP violations. Low-priority violations (analytics services failing to load) might be informational only. High-priority violations (script execution blocked) warrant investigation. Establish clear thresholds for escalation and automated alerts for suspicious violation patterns.

CSP is one defense layer in defense-in-depth. Input Validation and Output Encoding: These are primary defenses—validate all user input on the server and output-encode it appropriately (HTML encoding for HTML context, JavaScript encoding for JavaScript context, URL encoding for URLs). These should always be your first line of defense. CSP is a second line catching XSS attempts that bypass primary defenses.

HTTPOnly and Secure Cookies: Even with successful XSS, HTTPOnly cookies can't be accessed by JavaScript, preventing attackers from stealing session cookies. Set HTTPOnly flag on sensitive cookies (authentication tokens) and Secure flag to transmit only over HTTPS. This reduces the value of successful XSS—attackers can't easily steal session tokens.

X-XSS-Protection Header: This legacy header (X-XSS-Protection: 1; mode=block) enables older browser XSS filters that detect and block suspicious scripts. While modern browsers rely on CSP instead, this header provides defense in older browsers. CSP supersedes this header in modern browsers.

X-Frame-Options: This header prevents clickjacking attacks by controlling whether your page can be embedded in iframes. While not directly related to XSS, it prevents attackers from tricking users into interacting with your page in attacker-controlled contexts. Set X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN.

Subresource Integrity (SRI): When loading external resources (scripts, stylesheets) from CDNs, use SRI to verify they haven't been modified. Include a hash in the <script> tag; the browser verifies the downloaded resource matches the hash before executing it. This prevents CDN compromises or man-in-the-middle attacks from injecting malicious code. CSP and SRI together provide comprehensive defense against script injection attacks.