Free Content Security Policy (CSP) Checker

Free tool

Scan your Content Security Policy for unsafe-inline, unsafe-eval, missing object-src and base-uri, and weak sources. Get nonce and strict-dynamic fixes you can ship today.

  • CSP directives analysis
  • Detect unsafe-inline/eval
  • CSP violation detection
No credit card requiredProduction-safe (100% passive)No setup or code required
Used by 5,000+ developers and engineering teams
Oracle logoShopify logoGoDaddy logoChubb logoToshiba logoMAPFRE logoBelfius logoHolcim logo

What you get for free

18 core security checks via this tool, passive scans, step-by-step remediation, security score on every result.

What Essential adds from $99/mo

Pentest credits every month, +17 advanced checks, weekly continuous monitoring, email alerts, GitHub fix PRs, audit-ready PDFs for SOC 2 / ISO 27001 / PCI.

What is Content Security Policy (CSP)?

CSP is a browser security layer that controls where your app can load resources from (scripts, styles, images, frames, etc.). A strict policy prevents XSS and reduces supply-chain risk by blocking unexpected sources.

Why CSP matters

A strong CSP can neutralize whole classes of injection bugs and mitigate third-party script risk. It also provides defense in depth when combined with escaping, sanitization, and Trusted Types.

How to fix common failures

  • Replace script-src 'unsafe-inline' with nonces (rotate per request)
  • Add object-src 'none'; base-uri 'none'; form-action 'self'
  • Audit third-party domains and restrict to explicit allow-lists
  • Enable upgrade-insecure-requests and avoid mixed content

Examples (good vs bad)

Bad: script-src 'self' 'unsafe-inline' https://cdn.example.com

Better: script-src 'self' 'nonce-...' 'strict-dynamic' https://cdn.example.com; object-src 'none'; base-uri 'none'

What this checker validates

  • Detects unsafe directives (unsafe-inline, unsafe-eval)
  • Flags missing baselines: object-src 'none', base-uri 'none'
  • Evaluates nonce/hash usage and recommends strict-dynamic
  • Reviews frame-ancestors, form-action, upgrade-insecure-requests
  • Monitors CSP console errors to identify blocked legitimate resources

Across 7,440 recent scans, 98.9% are missing a strict Content Security Policy, and 98.0% have no Trusted Types directive.

Implementation examples

Once you've identified the gap, applying the fix is straightforward. Here are the configurations developers reach for most often.

Nginx

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-$request_id' 'strict-dynamic'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests" always;

Apache

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-%{CSP_NONCE}e' 'strict-dynamic'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests"

Node.js (Express + Helmet)

import crypto from "node:crypto"
import express from "express"
import helmet from "helmet"

const app = express()

app.use((req, res, next) => {
  res.locals.cspNonce = crypto.randomBytes(16).toString("base64")
  next()
})

app.use(
  helmet({
    contentSecurityPolicy: {
      useDefaults: false,
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: [
          "'self'",
          (_req, res) => `'nonce-${res.locals.cspNonce}'`,
          "'strict-dynamic'",
        ],
        objectSrc: ["'none'"],
        baseUri: ["'none'"],
        formAction: ["'self'"],
        frameAncestors: ["'none'"],
        upgradeInsecureRequests: [],
      },
    },
  }),
)

Next.js (middleware.ts, per-request nonce)

// middleware.ts - Next.js applies the nonce to its own
// inline scripts when the CSP arrives on the request headers.
import { NextResponse } from "next/server"

export function middleware(request) {
  // btoa works in both the Edge and Node middleware runtimes
  const nonce = btoa(crypto.randomUUID())
  const csp =
    "default-src 'self'; " +
    "script-src 'self' 'nonce-" + nonce + "' 'strict-dynamic'; " +
    "object-src 'none'; base-uri 'none'; form-action 'self'; " +
    "frame-ancestors 'none'; upgrade-insecure-requests"

  const requestHeaders = new Headers(request.headers)
  requestHeaders.set("content-security-policy", csp)

  const response = NextResponse.next({ request: { headers: requestHeaders } })
  response.headers.set("Content-Security-Policy", csp)
  return response
}

A static next.config.mjs headers entry cannot rotate nonces, and script-src 'self' on its own blocks the inline bootstrap scripts Next.js renders, so the CSP belongs in middleware. On Netlify and similar hosts, static header files have the same limitation.

Tool-specific questions

What does a CSP checker test?

A CSP checker inspects the Content-Security-Policy header your site sends and evaluates it for risky directives like unsafe-inline, unsafe-eval, and wildcard sources. These allow injected scripts to run and are a primary target for XSS attacks. Barrion's free tool identifies gaps and provides guidance on switching to nonces, hashes, and strict-dynamic for a secure, modern CSP.

Should I use nonces or hashes?

For dynamic apps, prefer nonces with strict-dynamic. For static inline scripts, hashes are fine. Avoid unsafe-inline entirely.

Do I need object-src and base-uri even if unused?

Yes. Set object-src 'none' and base-uri 'none' to close legacy vectors and prevent base tag abuse.

Can I allow *.cdn.com wildcards?

Use precise hosts over broad wildcards. Prefer scheme+host allow-lists to limit blast radius.

How often should CSP nonces rotate?

Per response/request. Never reuse nonces across requests.

How do I migrate from unsafe-inline to nonces?

Identify inline scripts, move logic to external files where possible, add per-response nonces to remaining inline scripts, and include the nonce in script-src with strict-dynamic. Remove unsafe-inline once all critical scripts are covered.

Why do third-party widgets get blocked?

Widgets load scripts, frames, or styles from external origins. Add only the required hosts to your CSP allow-list and prefer provider guidance on exact domains. Avoid broad wildcards.

Does Barrion catch a CSP that breaks my site?

Barrion flags policies that are likely to block resources your site needs, such as missing sources or unsafe directives, from the header alone. Live violations only show up in the browser's developer console, where they can silently break features or stop third-party services (analytics, widgets, CDNs) from loading. Our checks help you catch a policy that is too tight before it does that, while keeping it strong.
Why Barrion

Built for the engineers who already have enough to fix.

Speed

Real-time results

Instant analysis with a detailed report. You see findings as the scan runs, not after.
Coverage

Comprehensive checks

35+ checks per scan covering TLS, headers, CORS, cookies, DNS, email auth, and more, in a single pass.
Action

Step-by-step fixes

Every finding ships with the exact remediation step for your framework. Hand it to the engineer who owns the surface.
FAQ

Frequently asked.

What is Barrion and how does it enhance website security?
Barrion is a security testing and monitoring platform for engineering teams, and it works in two ways. Passive scanning keeps a continuous, read-only watch over your live web apps and APIs. AI pentesting goes on the offensive, running agent-driven attacks that prove which vulnerabilities are genuinely exploitable. Every finding comes with a step-by-step fix you can ship right away.
How safe is Barrion to use for security testing?
Passive scanning is completely safe to run, including against production. Passive scans only read your live app, so we never submit forms, brute-force endpoints or touch anything that changes state. AI pentesting is more aggressive by design, since its job is to confirm real exploits, so it runs rate-limited and non-destructive, and you approve the exact scope before a single request is sent.
What types of security issues does Barrion identify?
It depends on the surface. On your live apps, Barrion catches misconfigurations across TLS and HTTPS, security headers, cookie flags, CORS policy, DNS records, email authentication (SPF, DKIM, DMARC), network exposure and the usual web hygiene gaps. AI pentesting surfaces the exploitable stuff, like SQL injection, cross-site scripting and broken access control, each one backed by proof it can actually be exploited.
What specific security checks does Barrion perform?
Barrion covers two surfaces. Passive web scanning is read-only and safe to point at production, and runs 35+ checks: transport security (HTTPS, HSTS, TLS version, cipher suites, certificate expiry, hostname and chain validity, OCSP stapling), HTTP response headers (Referrer-Policy, Permissions-Policy, X-Content-Type-Options, Content-Type, server information disclosure), CSP and framing (Content-Security-Policy, bypass detection, Trusted Types, X-Frame-Options), cross-origin policy (COOP, COEP, CORP and the full CORS header set), cookie flags and anti-CSRF tokens, mixed content, vulnerable JavaScript libraries, DNS records including DNSSEC and CAA, email authentication (SPF, DKIM, DMARC), open ports and subdomain takeover. AI pentesting is the aggressive surface: it actively chains requests to confirm exploitable flaws such as SQL injection, cross-site scripting and broken access control, and returns reproducible proof for each one. Findings from both are ranked by severity and come with step-by-step remediation.
What is Barrion's smart crawling?
Smart crawling automatically discovers the pages and endpoints of your app so scans cover the surface that matters, without you manually listing every URL.
How often does Barrion perform security scans?
You can run a scan manually whenever you want. Continuous monitoring of your live apps runs on its own (weekly on Essential, daily on Business), and we alert you the moment something new shows up.
Is Barrion suitable for security testing of all business sizes?
Yes. Live-app monitoring and AI pentesting work just as well for a solo developer as for a startup, a scale-up or an enterprise security team, and it fits alongside the tools you already run.
How does Barrion handle data security and privacy during security testing?
Live-app scans are read-only by default, and we never store or expose sensitive data from your application. AI pentests are rate-limited and non-destructive, built to confirm whether something is exploitable without altering your data or affecting availability.
What if I'm not satisfied with Barrion's security testing service?
You can cancel anytime in the dashboard, and paid plans carry a 14-day refund window from the first charge. If something isn't right, contact us and we'll make it work for your team.
How does Barrion help with SOC 2, ISO 27001, NIS2, and other compliance frameworks?
Barrion produces audit-ready PDF and CSV reports suitable for SOC 2, ISO 27001, PCI DSS and NIS2, ready to share with auditors, customers and your board.

Anything else? Email contact@barrion.io.

A scan shows the surface. A pentest proves what gets in.

Passive scan

  • Reads what your app already exposes
  • Never logs in or submits a form
  • Cannot confirm what is exploitable

Active AI pentest

  • Attacks your app like a real hacker
  • Chains requests to confirm real exploits
  • Reproduces every finding as proof

Probes for

  • SQL injection
  • Broken access control
  • IDOR
  • SSRF
  • Business-logic abuse

How AI pentesting works

Paid in credits, no sales call. Standard and deeper runs include expert review.