Why is unsafe-inline a problem in a CSP?

Allowing unsafe-inline in script-src lets any inline script tag execute, which defeats most of the cross-site scripting protection a CSP is meant to provide. A strong policy uses nonces or hashes instead so only known-good inline scripts run.

What does frame-ancestors protect against?

The frame-ancestors directive controls which sites may embed your page in a frame, which is the modern defence against clickjacking. Without it, an attacker can frame your page invisibly over their own UI, so set frame-ancestors to none or self.

How is the strength score calculated?

The checker starts at 100 and subtracts a penalty for each risky pattern, weighting high-severity issues like unsafe-inline, unsafe-eval, and wildcard sources most heavily, and missing protective directives less. The remaining number is the score out of 100.

What is strict-dynamic and should I use it?

strict-dynamic lets scripts loaded by a trusted nonce or hash load further scripts without an explicit allowlist, simplifying CSP for modern apps. Combined with per-request nonces it is the recommended pattern, so the tool suggests it when no nonce or hash is present.

Does a high score mean my site is secure?

No. A strong CSP is one important layer, but the checker only inspects the header string you paste. It cannot see whether nonces are truly per-request, whether other headers are set, or whether your application has other vulnerabilities.

Content Security Policy (CSP) Header Strength Checker

A Content Security Policy is one of the strongest defences against cross-site scripting and data injection, but a single weak source can quietly undo it. This checker parses your CSP header, flags the patterns attackers exploit, and scores the overall strength so you can harden it directive by directive.

How it works

The tool splits the header on semicolons into directives and inspects the effective sources, falling back to default-src where a specific directive is absent. It then applies a weighted penalty for each risky pattern it finds:

High severity: 'unsafe-inline', 'unsafe-eval', a wildcard *, or data: in script-src — each substantially weakens XSS protection.
Medium severity: missing default-src, object-src not set to 'none', missing frame-ancestors, or an http: source allowing mixed content.
Low severity: no nonce, hash, or strict-dynamic; 'unsafe-inline' styles; or a missing base-uri.

The score starts at 100 and each penalty is subtracted, giving a final strength figure and a band of Weak, Moderate, or Strong.

Example

The policy script-src 'self' 'unsafe-inline' parses cleanly but loses 30 points for 'unsafe-inline', because inline scripts can execute and defeat the policy. Replacing it with a per-request nonce and adding frame-ancestors 'none' and base-uri 'self' recovers most of the score.

Tips and notes

Aim to remove 'unsafe-inline' and 'unsafe-eval' entirely, prefer nonces or hashes with strict-dynamic, and always set object-src 'none', frame-ancestors, and base-uri. The checker only reads the string you paste, so it cannot confirm that your nonces are genuinely unique per response — verify that in your application.