Audit your domain

Content Security Policy

Block XSS attacks and code injection

Back to SSL & Security

What we check

We verify your site has a Content Security Policy header

We check that your site has a Content Security Policy (CSP) header configured to prevent XSS attacks. CSP is a security header that tells browsers which resources are allowed to load on your site, blocking malicious scripts and unauthorized content.

Security Impact

Why Content Security Policy is critical

XSS attacks are extremely common

Cross-site scripting (XSS) is one of the most common web vulnerabilities. Attackers inject malicious scripts to steal data, hijack sessions, or deface your site.

CSP is your last line of defense

Even if an XSS vulnerability exists in your code, CSP prevents the malicious script from executing, blocking the attack before it causes damage.

Data theft and session hijacking

Without CSP, successful XSS attacks can steal user credentials, session tokens, payment information, and other sensitive data.

Prevents unauthorized code execution

CSP blocks inline scripts, eval(), and unauthorized external scripts from running on your site, significantly reducing attack surface.

Implementation

How to implement Content Security Policy

With Httpeace

Httpeace automatically checks if CSP is configured on your site:

  • Add your domain to Httpeace
  • We check for CSP headers automatically every day
  • Get instant alerts if CSP is missing or improperly configured
  • See recommended CSP directives in your dashboard

Without Httpeace

Manual CSP implementation requires careful testing and ongoing monitoring:

# Check if CSP header is present
curl -I https://yourdomain.com | grep -i content-security-policy

# Test CSP violations in browser console
# 1. Open DevTools Console
# 2. Look for CSP violation warnings
# 3. Note which resources are blocked

# Validate CSP syntax
# Visit: https://csp-evaluator.withgoogle.com/

# Test with report-only mode first
curl -I https://yourdomain.com | \
  grep -i content-security-policy-report-only

# Parse CSP violation reports
# Set up endpoint to receive violation JSON
# Parse and analyze which policies are blocking what

You'll need to:

  • Learn complex CSP directive syntax (default-src, script-src, style-src, etc.)
  • Start with report-only mode to avoid breaking your site
  • Set up reporting endpoint to receive and log CSP violation reports
  • Analyze violation reports to understand what resources are blocked
  • Gradually refine policy to allow legitimate resources while blocking threats
  • Test every page and feature to ensure nothing breaks
  • Handle inline scripts by using nonces or hashes (complex setup)
  • Configure CSP in server config (Nginx/Apache) or Next.js middleware
  • Test with different content types (pages, API routes, static files)
  • Monitor daily to ensure CSP header stays configured after deployments
  • Update CSP when adding new third-party scripts or CDNs
  • Deal with browser compatibility differences in CSP support
  • Create and test basic CSP header with restrictive defaults
  • Implement server-specific configurations for Nginx, Apache, or Next.js
  • Set up CSP reporting infrastructure to collect violation data

CSP is notoriously difficult to implement correctly. Too restrictive breaks your site, too permissive provides no protection. Finding the right balance requires extensive testing and constant maintenance.

FAQ

Frequently asked questions

What is XSS (Cross-Site Scripting)?

XSS is a vulnerability where attackers inject malicious scripts into your website. These scripts execute in your users' browsers, allowing attackers to steal data, hijack sessions, or manipulate content. CSP prevents these scripts from running.

Will CSP break my site?

CSP can break sites that rely on inline scripts, eval(), or external scripts. Start with Content-Security-Policy-Report-Only to test your policy without blocking anything. Monitor violation reports and adjust your policy to allow legitimate resources.

What is the default-src directive?

default-src is the fallback for all resource types. Setting it to 'self' means only resources from your own domain are allowed by default. You can then override specific resource types like script-src or img-src as needed.

Should I use unsafe-inline?

Avoid unsafe-inline as it defeats much of CSP's protection. Instead, use nonces or hashes for specific inline scripts, or better yet, move all scripts to external files. Only use unsafe-inline if absolutely necessary and you understand the security trade-offs.

How does Httpeace check for CSP?

Httpeace makes requests to your site and checks for the Content-Security-Policy or Content-Security-Policy-Report-Only header. We verify it exists and is properly formatted. We alert you if the header is missing or invalid.

Related checks

Other checks in this category

HSTS Header

Force HTTPS to prevent downgrade attacks and man-in-the-middle attacks.

SSL Certificate Expiry

Prevent browser warnings by monitoring certificate expiration dates.

SSL Certificate Validity

Ensure encrypted connections are trusted by validating certificate chains.

Subdomain Takeover

Prevent attackers from hijacking dangling subdomains.

View all SSL & Security checks

Peace of mind for your domains.

Start monitoring today and prevent outages, hacks, and costly mistakes.

Audit your domain — it's freeTalk to us