Issue 137

This issue checks whether your website sends a Content-Security-Policy (CSP) HTTP response header to control which resources can be loaded and executed on your pages.

What this issue checks

• The CSP header is present in HTTP responses
• The policy restricts resource loading to trusted sources
• The policy does not use overly permissive directives like unsafe-inline or unsafe-eval in script-src
• The policy covers all necessary resource types (scripts, styles, images, fonts, etc.)

What is considered a passing implementation

A passing implementation means:

• The CSP header is present in HTTP responses
• The policy restricts resource loading to trusted sources
• The policy avoids unsafe-inline and unsafe-eval in script-src
• The policy covers all necessary resource types

Real-world example

A properly configured CSP header looks like:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; style-src 'self' 'unsafe-inline';

This tells browsers to only load resources from your own domain by default, allow scripts from your domain and a trusted CDN, and allow inline styles (but not inline scripts).

CSP is important for website security and SEO:

Crawlability

If your site is vulnerable to XSS attacks, attackers could inject malicious content or links that search engines might index, harming your SEO.

Indexability

Similar to crawlability, security vulnerabilities can lead to indexing issues if malicious content is injected into your pages.

Rankings

Google considers site security as a ranking factor. Sites with strong security headers like CSP signal quality and trustworthiness to search engines.

User Experience

CSP prevents cross-site scripting (XSS) attacks, which can steal user data, hijack sessions, or redirect users to malicious sites. A successful XSS attack severely damages user trust.

AI Search / AEO

AI-powered search engines and assistants prioritize secure, trustworthy sites. CSP demonstrates your commitment to security best practices.

Compliance

Many security standards (PCI DSS, HIPAA) recommend or require CSP headers for data protection.

SEO Health Score Impact

Resolving this issue improves your overall SEO health score by protecting your site from XSS attacks and demonstrating strong security practices.

Follow these steps to implement CSP properly:

Step 1: Audit your resource requirements

Audit your resource requirements to identify all domains and resource types your site loads (scripts, stylesheets, images, fonts, etc.).

Step 2: Start with Report-Only mode

Start with Report-Only mode to test your policy without blocking resources:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Step 3: Create a restrictive baseline policy

Create a restrictive baseline policy using default-src 'self' to only allow resources from your own domain by default.

Step 4: Add specific directives

Add specific directives for each resource type:

• script-src for JavaScript
• style-src for CSS
• img-src for images
• font-src for fonts
• connect-src for AJAX/fetch requests
• frame-src for iframes

Step 5: Avoid unsafe-inline and unsafe-eval

Avoid unsafe-inline and unsafe-eval in script-src. Instead, use nonces or hashes for inline scripts that are absolutely necessary.

Step 6: Test thoroughly

Test thoroughly by monitoring CSP violation reports and adjusting the policy as needed.

Step 7: Deploy the enforcing policy

Deploy the enforcing policy once tested:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self';

Step 8: Apply to all pages

Apply to all pages by configuring your web server, CDN, or application framework to send the CSP header on all HTTP responses.

Example 1: Missing CSP Header

Problem: The CSP header is not present in HTTP responses.

What fails:

HTTP response does not include Content-Security-Policy header

What passes:

Content-Security-Policy: default-src 'self'

Example 2: Overly Permissive CSP

Problem: The CSP policy uses unsafe-inline in script-src.

What fails:

Content-Security-Policy: script-src 'unsafe-inline' 'unsafe-eval'

What passes:

Content-Security-Policy: script-src 'self' https://trusted-cdn.com

Example 3: Proper CSP Configuration

Scenario: A well-configured CSP that restricts resources to trusted sources.

What passes:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self'; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com;

This policy allows resources only from trusted sources and avoids unsafe directives.

PixyScan checks whether your website sends a Content-Security-Policy (CSP) HTTP response header to control which resources can be loaded and executed on your pages.

Detection process

PixyScan follows these logical steps to identify CSP header issues:

1. Check for CSP header - PixyScan looks for the Content-Security-Policy header in the HTTP response.

2. Validate header value - If the CSP header is present, PixyScan checks:

   • The header value is not empty or malformed
   • The policy restricts resource loading to trusted sources
   • The policy does not use overly permissive directives like unsafe-inline or unsafe-eval in script-src

3. Analyze policy coverage - PixyScan examines whether the policy covers all necessary resource types (scripts, styles, images, fonts, etc.).

When the issue is flagged

The issue is flagged when any of these conditions are met:

• The CSP header is missing in HTTP responses
• The CSP header value is empty or malformed
• The policy uses unsafe-inline or unsafe-eval in script-src directive
• The policy is overly permissive (uses * or data: in sensitive directives)

When the issue passes

The issue passes when:

• The CSP header is present in HTTP responses
• The policy restricts resource loading to trusted sources
• The policy avoids unsafe-inline and unsafe-eval in script-src
• The policy covers all necessary resource types