Content Security Policy Checker

A useful check does more than say whether the header exists. CSP quality depends on directives, source lists, fallback behavior, reporting, and whether sensitive pages are protected.

• Whether the site sends Content-Security-Policy or Content-Security-Policy-Report-Only.
• Whether default-src, script-src, style-src, img-src, connect-src, frame-src, frame-ancestors, object-src, and base-uri are defined where appropriate.
• Whether script rules rely on unsafe-inline, unsafe-eval, broad wildcards, data URLs, or overly permissive third-party domains.
• Whether framing protection uses frame-ancestors for sensitive pages.
• Whether report-only mode is used for rollout and testing before enforcement.
• Whether payment, analytics, maps, chat, media, and marketing tools are intentionally allowed rather than broadly whitelisted.

CSP often fails in two opposite ways. Some websites have no policy at all. Others copy a strict template and accidentally break legitimate scripts, payment widgets, embeds, or analytics.

• No CSP on pages that accept input, display user content, or run many third-party scripts.
• Policies that allow every source with a wildcard.
• script-src using unsafe-inline or unsafe-eval without a migration plan.
• Missing frame-ancestors on login, account, payment, or admin pages.
• Report-only policies that never collect or review violation reports.
• Multiple conflicting policies added by application code, CDN, plugins, and hosting rules.

A safe CSP rollout starts with observation. Report-only mode lets teams see what would be blocked without enforcing the policy yet. That is especially useful for sites with analytics, tag managers, payment scripts, ads, maps, chat widgets, or third-party embeds.

1. Inventory scripts, frames, images, fonts, APIs, and third-party services used by important pages.
2. Start with a report-only policy for sensitive flows.
3. Review violation reports and browser console errors.
4. Replace broad sources with specific domains where possible.
5. Move inline scripts toward nonces, hashes, or external scripts where practical.
6. Enforce gradually and test login, checkout, forms, search, admin, and marketing pages.
7. Monitor after deployments so new scripts do not silently weaken the policy.

Fixnx reviews CSP as part of website security headers and browser-facing hardening. It can identify missing policies, weak patterns, framing gaps, and cases where CSP should be reviewed alongside XSS, third-party script, and sensitive-page risk.

A public CSP check cannot prove that every script is safe. It helps website owners see whether the browser has meaningful guardrails and whether the policy is likely to be too weak or too risky to enforce without testing.