hidekazu-konishi.com

About This Tool

A Content Security Policy (CSP) is an HTTP response header (or <meta> tag) that tells the browser which sources of script, style, images, and other resources a page is allowed to load - a primary defense against cross-site scripting (XSS) and a control for clickjacking and other injection attacks. Writing one by hand is error-prone: the directive names, the quoting rules for keywords like 'self' and 'unsafe-inline', and the subtle interactions between 'strict-dynamic', nonces, and host allowlists are easy to get wrong. This tool helps on both sides, entirely in your browser:

• Builder: assemble a policy directive by directive and copy it as an HTTP header, a policy value, or a <meta> tag - with Content-Security-Policy and Content-Security-Policy-Report-Only both supported.
• Linter: paste an existing policy to get line-by-line Error / Warning / Info results, each labeled as derived from the specification or as this tool's recommendation.

Directive names, source keywords, and deprecation status were confirmed against the official documentation as of 2026-06-23. The specification and browser support evolve; re-check the sources below for the current set.

Specification Sources

• MDN - Content-Security-Policy header reference (directive list and per-directive status): developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy
• MDN - Content Security Policy guide (source keywords, nonces, hashes, strict-dynamic, reporting): developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
• W3C - Content Security Policy Level 3 specification: w3.org/TR/CSP3/

Directive Reference

The directives this tool understands, by category, confirmed against MDN as of 2026-06-23. Deprecated and experimental directives are built only so the Linter can flag them.

Source Keyword Reference

Keyword sources must be wrapped in single quotes. Nonces and hashes are also quoted. Host sources (example.com, *.example.com) and scheme sources (https:, data:, blob:) are written without quotes.

Linter Rules

Each check is labeled spec (defined or required by the specification) or recommendation (a hardening suggestion). No rule here invents a requirement the specification does not state.

How to Use

1. Builder tab: for each directive, tick the keyword sources and type any hosts, schemes, nonces, or hashes. Add more directives from the picker, set advanced and reporting directives, and toggle Report-Only if you are still testing.
2. Copy the HTTP header, the policy value, or the <meta> tag. Watch the inline review for weak settings as you build.
3. Linter tab: paste an existing policy (or load an example) and click "Check" (or press Ctrl+Enter / Cmd+Enter) for line-by-line Error / Warning / Info results.
4. Copy Report to take the findings into a pull request or review checklist.

Features:

• 🛠️ Directive Builder: Data-driven directive rows that offer only the keywords valid for each directive, plus host / scheme / nonce / hash entry
• 📄 Three Output Forms: HTTP header, policy value, and <meta> tag, with Content-Security-Policy and -Report-Only both supported
• 🔍 Linter: Tokenizes a pasted policy and reports Error / Warning / Info, each labeled spec or recommendation
• 🏷️ Spec vs. Recommendation: Every finding states whether it comes from the specification or is a hardening suggestion - no invented rules
• 📋 Examples and Copy Report: Strict, moderate, and common-loose presets plus a copyable text report
• 🔒 Privacy First: All processing happens locally - no data sent to servers, no request is made, no URL is fetched
• ⌨️ Keyboard Shortcut: Ctrl+Enter (Cmd+Enter) runs the Linter

FAQ

What is the difference between 'self' and 'none'?

'self' allows resources from the page's own origin (same scheme, host, and port). 'none' blocks every source for that directive and must appear on its own - combining it with any other source is a syntax error. Use 'none' for directives you want fully locked down, such as object-src 'none'.

Is 'unsafe-inline' safe to use?

No - it is named "unsafe" for a reason. It allows inline <script> and event handlers, which is one of the most common XSS vectors and defeats much of the point of a CSP. Prefer a per-response 'nonce-...' or a content 'sha256-...' hash. Note that when a nonce or hash is present, browsers that support them ignore 'unsafe-inline', so it can remain only as a fallback for very old browsers.

Should I use the HTTP header or the <meta> tag?

The HTTP response header is the recommended, fully featured delivery method. A <meta> tag is handy when you cannot set headers, but several directives - frame-ancestors, sandbox, report-uri, and report-to - have no effect in a <meta> tag, and Content-Security-Policy-Report-Only cannot be delivered that way at all. This tool flags those cases.

What does 'strict-dynamic' do?

It tells the browser to trust scripts that already carry a valid nonce or hash to load further scripts, without those additional scripts needing their own nonce or hash. In supporting browsers it also causes host and scheme allowlist entries in that directive to be ignored, so trust flows through nonces/hashes rather than URL allowlists - a more robust pattern for modern apps with third-party scripts.

What is the difference between enforce and Report-Only?

Content-Security-Policy enforces the policy: violating resources are blocked. Content-Security-Policy-Report-Only blocks nothing - it only reports what would have been blocked, which lets you test a policy safely before enforcing it. You can even send both headers at once: one enforced and one stricter policy in Report-Only to measure the next tightening.

Important Notes

• CSP directives and keywords evolve. This builder follows the specification as of 2026-06-23. Warnings are best-effort guidance, not a security audit - a policy without warnings is not guaranteed to be safe. Always test in Report-Only mode before enforcing.
• The Linter checks syntax and known weak settings. It cannot know your application's real resource needs, cannot confirm that a nonce is actually random and per-response, and cannot verify that a host you allowlist is itself trustworthy.
• Every finding is a flag for review, not a verdict. A clean result means none of this tool's checks matched - treat it as one input to a manual review, not a safety certificate.
• Browser support for individual directives and keywords differs. Confirm behavior against the official sources above and your own testing across the browsers you target.
• This tool never applies a policy to a real site, never sends a request, and never fetches any URL. All processing happens locally in your browser.

Related Tools

• HTTP Security Header Analyzer Tool - paste real response headers to grade CSP and the other security headers
• Meta Tag and OGP Generator Tool - generate the <head> meta and Open Graph tags for a page
• URL Encoder and Decoder Tool - encode and decode URLs and report endpoints used in a policy
• CORS Policy Tester Tool - simulate CORS preflight and Access-Control headers for the endpoints in your policy

Related Articles

• HTTP Security Headers Complete Reference - how Content-Security-Policy fits alongside the other response security headers
• AWS Secure Web Application Reference Architecture Guide - delivering security headers from CloudFront, ALB, and the application tier