How to Check Content Security Policy Headers with OpDeck's Scanner

If you want to know how to check Content Security Policy headers on your website, you have a few options — from browser developer tools to command-line utilities to dedicated security scanners. This guide walks you through all of them, explains what you're actually looking for when you inspect a CSP header, and shows you how to use OpDeck's Vulnerability Scanner to get a thorough, actionable security report in seconds.

What Is a Content Security Policy Header and Why Does It Matter?

A Content Security Policy (CSP) is an HTTP response header that tells the browser which content sources are allowed to load on your page. When configured correctly, it acts as a powerful defense against cross-site scripting (XSS) attacks, clickjacking, and data injection attacks — some of the most common and damaging vulnerabilities on the web.

Here's what a basic CSP header looks like in an HTTP response:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *; object-src 'none'

Each directive defines a specific category of resource:

• default-src — The fallback for any resource type not explicitly defined
• script-src — Controls which JavaScript sources are permitted
• style-src — Governs CSS loading
• img-src — Specifies allowed image origins
• object-src — Controls plugins like Flash (typically set to 'none')
• connect-src — Restricts URLs for fetch, XHR, and WebSocket connections
• frame-ancestors — Prevents your page from being embedded in iframes (mitigates clickjacking)

If your site doesn't send a CSP header at all, browsers have no restrictions on what can be loaded — leaving you exposed to script injection attacks where malicious code could be silently inserted into your pages.

How to Check Content Security Policy Headers Using Browser DevTools

The fastest manual method is your browser's built-in developer tools. Here's how to do it in Chrome (the process is nearly identical in Firefox and Edge):

Step 1: Open the Network Tab

1. Navigate to the website you want to inspect
2. Right-click anywhere on the page and select Inspect (or press F12)
3. Click the Network tab
4. Reload the page with Ctrl+R (or Cmd+R on Mac)

Step 2: Find the Main Document Request

In the Network panel, click on the first request — this is typically the HTML document itself. Look for the entry that matches your domain name.

Step 3: Check the Response Headers

Click on that request, then select the Headers tab in the right panel. Scroll down to the Response Headers section. You're looking for:

• Content-Security-Policy — The enforced policy
• Content-Security-Policy-Report-Only — A monitoring-only policy that logs violations without blocking them

If neither header is present, your site has no CSP configured.

Reading the Output

When you find the header, you'll see a long string of directives separated by semicolons. Pay particular attention to:

• 'unsafe-inline' in script-src or style-src — This weakens your policy significantly because it allows inline scripts and styles, which is precisely what XSS attackers exploit
• 'unsafe-eval' — Permits eval() and similar dynamic code execution, another major risk
• Wildcard sources like * in script-src — Effectively defeats the purpose of the policy
• Missing object-src — If not set to 'none', plugins can be used as attack vectors
• Missing frame-ancestors — Leaves you open to clickjacking

How to Check Content Security Policy Headers via Command Line

If you prefer working in a terminal, curl is your best friend. This approach is particularly useful for automated checks, CI/CD pipelines, or when you need to test staging environments.

Using curl to Inspect Headers

curl -I https://example.com

The -I flag sends a HEAD request, which returns only the response headers without downloading the full page body. Your output will look something like this:

HTTP/2 200
content-type: text/html; charset=UTF-8
content-security-policy: default-src 'self'; script-src 'self' https://cdn.example.com
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=31536000; includeSubDomains

Filtering for Just the CSP Header

To isolate the CSP header specifically, pipe the output through grep:

curl -sI https://example.com | grep -i "content-security-policy"

The -s flag suppresses progress output, and -i in the grep makes the search case-insensitive.

Following Redirects

Many sites redirect from HTTP to HTTPS or from www to non-www. Add the -L flag to follow redirects:

curl -sIL https://example.com | grep -i "content-security-policy"

Testing with HTTPie

If you have HTTPie installed, it provides a more readable output:

http HEAD https://example.com

HTTPie colorizes and formats headers, making it easier to scan through a long list of response headers at a glance.

Checking Headers with Python

For developers who want to integrate CSP checks into scripts or testing frameworks:

import requests

response = requests.head("https://example.com")
csp = response.headers.get("Content-Security-Policy")

if csp:
    print(f"CSP Header Found:\n{csp}")
    directives = csp.split(";")
    for directive in directives:
        print(f"  - {directive.strip()}")
else:
    print("No Content-Security-Policy header found!")

This script fetches the headers, checks for the CSP, and breaks it down directive by directive — handy for logging or automated reporting.

Using OpDeck's Vulnerability Scanner to Check CSP Headers

While the manual methods above work well for one-off checks, they require you to know what you're looking for and interpret the results yourself. OpDeck's Vulnerability Scanner automates the entire process and gives you a clear, categorized security report that covers CSP alongside all other critical security headers.

How to Run a Scan

1. Go to https://www.opdeck.co/tools/vulnerability-scanner
2. Enter your website URL in the input field
3. Click Scan and wait a few seconds for the results

The scanner sends requests to your site, analyzes the full set of HTTP response headers, and evaluates them against current security best practices.

What the Scanner Checks

For Content Security Policy specifically, the scanner evaluates:

• Presence — Is the Content-Security-Policy header set at all?
• Directive coverage — Are critical directives like script-src, object-src, and frame-ancestors explicitly defined?
• Risky values — Does the policy include 'unsafe-inline', 'unsafe-eval', or overly broad wildcards?
• Report-Only mode — Is the policy still in monitoring mode rather than enforced?

Beyond CSP, the scanner also checks for other essential security headers that work alongside your policy:

• Strict-Transport-Security (HSTS) — Enforces HTTPS connections
• X-Content-Type-Options — Prevents MIME-type sniffing
• X-Frame-Options — Legacy clickjacking protection (now often handled by CSP's frame-ancestors)
• Referrer-Policy — Controls how much referrer information is shared
• Permissions-Policy — Restricts access to browser features like camera, microphone, and geolocation

Interpreting the Results

The scanner presents findings with severity levels — typically flagging missing headers as high-risk, misconfigured headers as medium-risk, and informational notes for headers that exist but could be tightened.

A common finding for many websites is a missing CSP header entirely. This gets flagged as a high-severity issue because without it, there's nothing preventing a compromised third-party script or an XSS vulnerability from executing arbitrary code in your users' browsers.

Another frequent finding is a CSP that includes 'unsafe-inline' in script-src. This often happens because developers add it as a quick fix when inline scripts break after adding a CSP — but it largely defeats the purpose. The scanner will flag this and you'll know to refactor those inline scripts to use nonces or hashes instead.

How to Fix Common CSP Issues

Once you've identified problems, here's how to address the most common ones.

Adding a CSP Header

Apache (.htaccess):

Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'"

Nginx:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'";

Node.js with Express (using the Helmet library):

const helmet = require('helmet');

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "https://cdn.example.com"],
      styleSrc: ["'self'"],
      imgSrc: ["'self'", "data:"],
      objectSrc: ["'none'"],
      frameAncestors: ["'none'"],
    },
  })
);

Replacing 'unsafe-inline' with Nonces

Instead of allowing all inline scripts, generate a unique nonce per request and include it in both the header and your script tags:

In your server code:

const crypto = require('crypto');
const nonce = crypto.randomBytes(16).toString('base64');

// Set the header
res.setHeader(
  'Content-Security-Policy',
  `script-src 'self' 'nonce-${nonce}'`
);

// Pass the nonce to your template
res.render('page', { nonce });

In your HTML template:

<script nonce="<%= nonce %>">
  // Your inline script here
</script>

This approach allows your specific inline scripts while blocking any injected scripts that don't carry the correct nonce.

Starting with Report-Only Mode

If you're adding CSP to an existing site and worried about breaking things, start with Content-Security-Policy-Report-Only and a report-uri directive:

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

This sends violation reports to your endpoint without blocking anything, so you can see what would break before enforcing the policy. Once you've reviewed the reports and adjusted the policy, switch to the enforced Content-Security-Policy header.

Automating CSP Checks in Your Workflow

For teams running continuous integration, it makes sense to bake CSP verification into your pipeline so regressions get caught before they reach production.

Simple Shell Script for CI

#!/bin/bash
URL="https://staging.example.com"
CSP=$(curl -sI "$URL" | grep -i "content-security-policy")

if [ -z "$CSP" ]; then
  echo "FAIL: No Content-Security-Policy header found on $URL"
  exit 1
else
  echo "PASS: CSP header found"
  echo "$CSP"
fi

Add this to your CI pipeline as a post-deployment check. If the header goes missing — perhaps due to a misconfigured deployment or a server config change — the build will fail and alert your team.

Using a GitHub Actions Step

- name: Check CSP Header
  run: |
    CSP=$(curl -sI https://staging.example.com | grep -i "content-security-policy")
    if [ -z "$CSP" ]; then
      echo "CSP header missing!"
      exit 1
    fi
    echo "CSP: $CSP"

This runs on every deployment to your staging environment, giving you a lightweight but effective security gate.

Other Security Headers Worth Checking Alongside CSP

Content Security Policy doesn't work in isolation. A complete security header setup includes several other headers that complement your CSP:

Header	Purpose
Strict-Transport-Security	Forces HTTPS, preventing protocol downgrade attacks
X-Content-Type-Options: nosniff	Prevents browsers from MIME-sniffing responses
X-Frame-Options	Blocks iframe embedding (superseded by CSP frame-ancestors but still worth setting for older browsers)
Referrer-Policy	Limits referrer data sent to third parties
Permissions-Policy	Restricts access to powerful browser APIs

When you run a scan with OpDeck's Vulnerability Scanner, all of these are checked simultaneously, so you get a complete picture of your security header posture in a single report rather than checking each one individually.

Conclusion

Knowing how to check Content Security Policy headers is a fundamental part of web security hygiene. Whether you're using browser DevTools for a quick manual inspection, curl for command-line checks, or a dedicated tool for comprehensive analysis, the important thing is that you're checking — and acting on what you find.

A missing or misconfigured CSP leaves your users exposed to some of the most exploitable vulnerabilities on the web. The good news is that fixing it is entirely within your control, and the process of checking your current state takes less than a minute.

Start by running your site through OpDeck's Vulnerability Scanner to get an immediate, clear report on your CSP and all other security headers. You'll see exactly what's missing, what's misconfigured, and where to focus your efforts — no security expertise required to read the results.