web validator

CSP SEO Validator & Content Security Policy Hardening Checker

Validate Content-Security-Policy headers for public-site hardening, unsafe directives, script/style sources, frame ancestors, reporting endpoints, and launch-readiness QA.

Results

Paste input and validate locally.
Status
Ready when you validate.
Details
Ready when you validate.
Issues
Ready when you validate.
Directives
Ready when you validate.

How to use this validator

  1. Capture the CSP header from the exact route you plan to ship, including the final redirected HTTPS URL.
  2. Paste the policy and run validation to check default-src, empty directives, unsafe-inline, unknown directives, frame-ancestors, and reporting coverage.
  3. Tighten script-src, style-src, object-src, base-uri, connect-src, img-src, font-src, frame-src, and frame-ancestors based on the page's real dependency list.
  4. Use report-only mode or report-to/report-uri during rollout so you can observe violations before enforcing a stricter production policy.
  5. Pair this with security headers, CORS, compression, performance budget, manifest, favicon, Open Graph, JSON-LD, canonical, sitemap, and robots validation before launch.

Rules & checks

Requires default-src as the fallback policy for scripts, styles, images, fonts, frames, media, and connections.

Flags empty directives except flag-style directives such as upgrade-insecure-requests and block-all-mixed-content.

Warns on script-src 'unsafe-inline' because it weakens XSS protection unless a nonce/hash migration is planned.

Highlights style-src 'unsafe-inline' as a migration tradeoff for framework styles, design systems, analytics widgets, and third-party embeds.

Encourages object-src 'none', base-uri 'self', and frame-ancestors for public-site hardening and clickjacking protection.

Recognizes report-to and report-uri as monitoring hooks so CSP violations can be reviewed before enforcing stricter policies.

Runs fully client-side; it does not fetch URLs, execute scripts, inspect response headers, validate nonce/hash correctness, or prove browser enforcement.

Inputs explained

  • Content-Security-Policy header from production or preview

    Paste the full CSP header value, not cookies or private request headers. Keep representative nonces/hashes if you need syntax review, but redact secrets, tokens, preview bypass values, and account-specific URLs.

When to use it

  • Run a public-site CSP launch checklist for marketing pages, validator pages, app shells, docs, pricing, checkout, login, and admin surfaces.
  • Compare Vercel preview and production CSP headers before merging framework, middleware, CDN, or reverse-proxy changes.
  • Review third-party script additions from analytics, pixels, tag managers, chat widgets, payments, auth, maps, forms, embeds, or A/B testing tools.
  • Turn CSP copied from curl, DevTools, Cloudflare, Nginx, Vercel, or a scanner into a local hardening checklist without uploading policy text.
  • Pair CSP QA with security headers, CORS, compression, performance budget, manifest, favicon, Open Graph, JSON-LD, canonical, sitemap, and robots validation.

Common errors

  • Shipping a policy without default-src, leaving fallback behavior unclear across script, style, image, font, frame, media, and connect directives.
  • Leaving script-src 'unsafe-inline' after launch because third-party snippets, analytics, tag managers, or old inline boot scripts were not inventoried.
  • Allowing broad sources like https:, data:, blob:, or * without narrowing them to the actual CDN, image, analytics, payment, auth, or embed providers.
  • Forgetting object-src 'none', base-uri 'self', and frame-ancestors on login, checkout, validator, lead-capture, admin, or app-shell routes.
  • Testing only the homepage even though framework middleware, static routes, API routes, redirects, and CDN edge rules can emit different CSP values.
  • Enforcing a strict CSP before collecting report-only violations, breaking real users or crawlers that rely on required scripts, styles, fonts, images, or embeds.

Limitations

  • Structure and basic risk checks only; this does not fetch a URL, inspect live response headers, execute JavaScript, or prove browser enforcement.
  • Does not compute or verify nonce/hash correctness against actual inline script/style content.
  • Does not replace a full CSP audit, browser violation reports, dependency inventory, XSS review, penetration testing, or security scanner output.
  • A policy can pass syntax checks and still break required production resources, crawlers, payment flows, auth, analytics, fonts, images, or embeds.

Tips

  • Start with Content-Security-Policy-Report-Only for complex sites, collect violations, then enforce once real dependencies are understood.
  • Prefer nonces or hashes for necessary inline scripts instead of leaving script-src 'unsafe-inline' on every public page.
  • Keep style-src exceptions intentional; some frameworks need inline styles, but design tokens, static CSS, and hashed styles can reduce risk.
  • Use frame-ancestors instead of only X-Frame-Options when you need modern, granular embedding rules.
  • Audit connect-src, img-src, font-src, frame-src, media-src, and worker-src whenever you add analytics, payments, auth, maps, uploads, or embeds.
  • Test through the CDN/edge layer and per route because redirects, static assets, image optimization, API responses, and app routes can diverge.

Examples

Stronger public-page policy

  • default-src 'self'; script-src 'self' https://cdn.example.com 'nonce-abc123'; style-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
  • Passes the basic structure checks and avoids broad script-src unsafe-inline.

Missing default-src fallback

  • script-src 'self'; object-src 'none'
  • Flags missing default-src so unlisted fetch directives do not inherit an accidental allowlist.

Unsafe script rollout

  • script-src 'self' 'unsafe-inline' https://analytics.example.com
  • Warns that inline scripts should move toward nonce/hash-based allowance or a carefully scoped exception.

Deep dive

CSP is the policy layer behind public-site trust: it helps constrain scripts, styles, embeds, and connections around SEO pages that also need performance, schema, Open Graph, and crawlability QA.

Use this validator after security headers to turn copied CSP policy text into a practical launch checklist for unsafe directives, source allowlists, frame ancestors, and reporting coverage.

The workflow stays local and evidence-based: paste a policy from curl, DevTools, Vercel, Cloudflare, Nginx, or a scanner and review hardening risks without uploading private headers or preview hostnames.

FAQs

Does this fetch my URL or execute scripts?
No. It validates pasted CSP text in your browser. Use curl, DevTools, report-only logs, browser consoles, and scanners to collect evidence first.
Is 'unsafe-inline' always wrong?
It is a risk signal, especially for script-src. Some style-src exceptions may be transitional, but production policies should prefer nonces, hashes, or static assets when practical.
Should I enforce CSP immediately?
For complex sites, start with Content-Security-Policy-Report-Only, collect violations, fix real dependencies, then enforce route by route.
Does CSP replace security headers?
No. Pair CSP with HSTS, nosniff, Referrer-Policy, Permissions-Policy, CORS, compression, and route-specific launch QA.

Related validators

web

Security Headers SEO Validator & Public Site Hardening Checker

Validate public-site HTTP security headers for HTTPS trust, response hardening, framing protection, referrer leakage, browser permissions, and launch-readiness QA.

web

CORS SEO Validator — API Origin Trust Checker

Validate Access-Control-Allow-* response headers for public API, app, CDN, and browser trust QA before frontend launches ship.

web

HTTP Compression Validator

Check HTTP response headers for gzip/br compression, numeric lengths, and basic ratios—client-side only.

web

Performance Budget SEO Validator & Core Web Vitals Risk Checker

Validate launch-readiness performance budgets locally for page weight, JavaScript, CSS, image bytes, request counts, and Core Web Vitals risk signals.

web

Web App Manifest SEO Validator & PWA Install QA

Validate manifest.json locally for PWA installability, mobile install metadata, app names, start_url, display mode, theme colors, and icon entries before launch.

web

Favicon SEO Validator & Brand Icon Checker

Check favicon, apple-touch-icon, Safari mask-icon, and public brand icon declarations locally so browser tabs, bookmarks, mobile home screens, search snippets, and pinned tabs use the right assets.

web

Open Graph & Twitter Card SEO Validator

Validate rendered Open Graph and Twitter/X card tags for search-result snippets, social previews, share-card images, absolute URLs, and launch QA before publishing.

web

JSON-LD SEO Validator & Rich Result Schema Checker

Validate rendered JSON-LD structured data for schema.org syntax, rich-result readiness, visible-content alignment, and crawlable schema blocks before publishing.

web

Canonical & hreflang Validator

Validate canonical URLs, hreflang alternates, x-default fallbacks, absolute target URLs, and duplicate-content signals before search engines cluster or localize pages incorrectly.

security

Hash Generator (MD5 / SHA1 / SHA256)

Generate MD5, SHA1, or SHA256 hashes locally—no data leaves your browser.

CSP validation runs entirely in your browser. Pasted policy text, private preview hostnames, nonce/hash examples, source allowlists, and route clues are not uploaded, logged, stored, fetched, or shared.

Structure and basic risk checks only; does not prove browser enforcement, nonce/hash validity, live route coverage, XSS safety, or production compatibility.