How do I handle third-party scripts and analytics?

Either add their origin to script-src (least preferred, brittle, and often bypassable), generate a nonce per response and inject the third-party script with that nonce, or use strict-dynamic so a trusted loader can pull the third-party script in. For analytics that inject iframes (such as some chat widgets), you also need to allow the iframe origin in frame-src and the connection in connect-src.

What is report-uri vs report-to?

report-uri is the older directive and is still supported by most browsers. report-to references a Reporting-Endpoints header (or the older Report-To header) that defines a named group of report destinations. Send both for now: report-to for modern Chromium browsers and report-uri as the fallback. Most reporting vendors accept both formats.

Should I include upgrade-insecure-requests and block-all-mixed-content?

upgrade-insecure-requests rewrites http:// resource URLs to https:// at the browser. It is a safe, modern default. block-all-mixed-content is the stricter form: it blocks any mixed-content request rather than upgrading it. Most teams ship upgrade-insecure-requests; the block variant is for sites that have already cleaned up their resource loading.

Does CSP affect SEO or performance?

CSP itself does not affect SEO. It is a response header, not page content. Performance impact is negligible for the policy header. The relevant performance trade-off is around nonces: generating a fresh nonce per response can defeat HTTP caching of the HTML, so most teams ship nonces for HTML and use hashes for static inline blocks.

Free Tool

Content Security Policy Generator
a strict CSP header in minutes

Generate a Content Security Policy header from a guided form. Pick directives, configure nonces and strict-dynamic, choose Report-Only or enforcing mode, and copy a ready-to-ship policy. Built for engineers rolling out CSP and pentesters writing remediation guidance. Runs entirely in your browser.

Get Started Free

No credit card required. Free plan available forever.

Delivery

Header mode

Mixed content handling

Resource directives

default-src

script-src

style-src

img-src

font-src

connect-src

frame-src

Inline content

Inline scripts

Inline styles

Frames, forms, and base URI

frame-ancestors

form-action

object-src

base-uri

Reporting

report-uri

Legacy directive but still widely supported.

report-to (group name)

References a group defined in your Reporting-Endpoints (or legacy Report-To) header.

Generated policy

1 warning

Header value

default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Full header line

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Warning: Report-Only mode without a report-uri or report-to endpoint is silent. Set at least one so violations are observable while you tune the policy.

Everything runs in your browser. Nothing is sent to a server.

How to roll out a Content Security Policy safely

A strict CSP almost always breaks something the first time it ships. Frameworks inject inline styles, analytics drop in iframes, marketing teams add a chat widget that fetches scripts from a third-party CDN, and a forgotten preview environment loads fonts from an origin no one remembered to allowlist. The reliable rollout pattern is to publish in Report-Only mode first, observe, fix, and only then enforce.

Generate the policy above and ship it as Content-Security-Policy-Report-Only. The browser reports violations but does not block anything.
Stand up a report endpoint (your own or a vendor) and set report-uri and report-to.
Run Report-Only for one to two release cycles. Each violation is either a real breakage to fix or a real risk to allowlist. Treat unexpected origins as a finding, not a noise complaint.
Fix legitimate violations: rewrite inline event handlers, move inline styles into stylesheets, add nonces to the inline blocks you cannot remove, and add the third-party origins your application actually uses.
Switch the header from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report endpoint active so regressions are still observable.
Iterate. Every new vendor, every new third-party widget, and every new subdomain is a CSP change. Track it like any other security control.

CSP directive reference

Directive	Controls
default-src	Fallback for every fetch directive that is not explicitly set. Set this first; only override specific directives where you need a different policy.
script-src	Origins and inline policies for JavaScript. The most security-relevant directive. Aim for `'self'` plus a nonce or `'strict-dynamic'`.
style-src	Origins for stylesheets and inline style policy. Inline style is less risky than inline script but still allows injection-driven UI redress.
img-src / font-src	Origins for images and fonts. `data:` is commonly added to img-src for inline icons.
connect-src	Origins for fetch, XHR, WebSocket, EventSource, and Beacon. Forget this and your API calls fail.
frame-src	Origins your page is allowed to frame. Use `'none'` unless you embed third-party widgets.
frame-ancestors	Origins allowed to frame your page. Modern equivalent of X-Frame-Options. Set to `'none'` unless your app must be embeddable.
form-action	Origins HTML forms are allowed to submit to. Stops a phishing iframe from posting to attacker endpoints.
object-src	Plugin content (object, embed, applet). Should be `'none'` for almost every modern app.
base-uri	Origins allowed in the document's `<base>` tag. Set to `'self'` or `'none'` to stop base-tag injection.
upgrade-insecure-requests	Rewrites `http://` resource URLs to `https://` at the browser. Safe modern default.
report-uri / report-to	Where the browser sends violation reports. Send both for now: report-uri for legacy support and report-to (with a Reporting-Endpoints header) for modern browsers.

Three policies to start from

Discovery (Report-Only)

Ship this first. Nothing breaks. Every violation flows to your report endpoint where you can sort real risks from forgotten origins.

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests; report-uri https://reports.example.com/csp

Strict modern policy with strict-dynamic

The OWASP-recommended pattern. Your trusted loader script (allowed by nonce) can pull in any dependency it needs without you maintaining a host allowlist. The trade-off is a fresh nonce per response, which complicates HTML caching.

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-{NONCE}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Same-origin static site

For sites that load everything from their own origin. Strict, simple, and a useful baseline before you start adding third-party origins.

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Where CSP fits in a pentest finding

Missing or weakly configured CSP is one of the most common findings in web application testing. It usually appears under security misconfiguration (OWASP Top 10 A05:2021) or as a contributing weakness alongside a reflected XSS finding. When writing it up for a client, a strong remediation block calls out the specific risk (XSS, clickjacking, mixed content), the recommended directive, and a copy-ready starter policy. The generator above produces the starter; the writeup belongs in the engagement record.

Related tools and resources

CSP is one piece of the response-header layer. The rest of the picture lives here.

Frequently asked questions

What does Content-Security-Policy actually protect against?

CSP is the browser-side defence against cross-site scripting, mixed content loading, clickjacking via frame-ancestors, and unintended data exfiltration. It does not replace input validation or output encoding; it tells the browser which origins it is allowed to load resources from and which inline content is permitted.

Should I start with Content-Security-Policy-Report-Only?

Yes. Report-Only mode publishes the policy but does not block anything; the browser only sends violation reports to the URL in report-uri or report-to. Run the policy in Report-Only for one to two release cycles, fix the violations that are legitimate, and only then switch to the enforcing header.

What is the difference between unsafe-inline, unsafe-eval, nonces, and hashes?

unsafe-inline allows any inline script or style and is the default unsafe escape hatch most apps reach for. unsafe-eval allows eval() and similar dynamic code. Nonces are per-response random tokens that a server adds to allowed inline tags and to the script-src directive. Hashes pin the SHA-256, SHA-384, or SHA-512 digest of a specific inline block.

Do I need both frame-ancestors and X-Frame-Options?

Modern browsers honour CSP frame-ancestors and ignore X-Frame-Options when both are present. Older browsers honour X-Frame-Options and ignore frame-ancestors. The pragmatic answer is to send both: frame-ancestors is more expressive, X-Frame-Options is the fallback for legacy clients.

What does strict-dynamic do?

'strict-dynamic' tells the browser to trust scripts that are loaded by an already-trusted script (one allowed by a nonce or hash). It lets you drop host whitelists from script-src and rely on the trust chain instead. This is the recommended pattern in OWASP guidance because host whitelists are easy to bypass through open redirects, JSONP endpoints, and abandoned subdomains.

Will a strict CSP break my site?

Almost certainly the first time you turn it on. That is what Report-Only mode is for. Common breakages include inline event handlers (onclick attributes), inline styles, dynamic eval, iframes from origins you forgot you used, and font or image CDNs that are not in the allowlist.

Loading tool...

Related features

Vulnerability scanning tools that map your attack surface

Vulnerability management software that tracks every finding

AI-powered reports in seconds, not days

Security testing for web applications

Cyber security assessments

Penetration testing

Want to verify the policy after you ship it?

SecPortal scans Content-Security-Policy alongside 15 other external modules and grades the response on a live engagement record. Start free.

Get Started Free

No credit card required. Free plan available forever.

Resource directives

default-src

script-src

style-src

img-src

font-src

connect-src

frame-src

How to roll out a Content Security Policy safely

Generate the policy above and ship it as Content-Security-Policy-Report-Only. The browser reports violations but does not block anything.

Stand up a report endpoint (your own or a vendor) and set report-uri and report-to.

Run Report-Only for one to two release cycles. Each violation is either a real breakage to fix or a real risk to allowlist. Treat unexpected origins as a finding, not a noise complaint.

Fix legitimate violations: rewrite inline event handlers, move inline styles into stylesheets, add nonces to the inline blocks you cannot remove, and add the third-party origins your application actually uses.

Switch the header from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report endpoint active so regressions are still observable.

Iterate. Every new vendor, every new third-party widget, and every new subdomain is a CSP change. Track it like any other security control.

CSP directive reference

Directive	Controls
default-src	Fallback for every fetch directive that is not explicitly set. Set this first; only override specific directives where you need a different policy.
script-src	Origins and inline policies for JavaScript. The most security-relevant directive. Aim for `'self'` plus a nonce or `'strict-dynamic'`.
style-src	Origins for stylesheets and inline style policy. Inline style is less risky than inline script but still allows injection-driven UI redress.
img-src / font-src	Origins for images and fonts. `data:` is commonly added to img-src for inline icons.
connect-src	Origins for fetch, XHR, WebSocket, EventSource, and Beacon. Forget this and your API calls fail.
frame-src	Origins your page is allowed to frame. Use `'none'` unless you embed third-party widgets.
frame-ancestors	Origins allowed to frame your page. Modern equivalent of X-Frame-Options. Set to `'none'` unless your app must be embeddable.
form-action	Origins HTML forms are allowed to submit to. Stops a phishing iframe from posting to attacker endpoints.
object-src	Plugin content (object, embed, applet). Should be `'none'` for almost every modern app.
base-uri	Origins allowed in the document's `<base>` tag. Set to `'self'` or `'none'` to stop base-tag injection.
upgrade-insecure-requests	Rewrites `http://` resource URLs to `https://` at the browser. Safe modern default.
report-uri / report-to	Where the browser sends violation reports. Send both for now: report-uri for legacy support and report-to (with a Reporting-Endpoints header) for modern browsers.

Three policies to start from

Discovery (Report-Only)

Ship this first. Nothing breaks. Every violation flows to your report endpoint where you can sort real risks from forgotten origins.

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests; report-uri https://reports.example.com/csp

Strict modern policy with strict-dynamic

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-{NONCE}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Same-origin static site

For sites that load everything from their own origin. Strict, simple, and a useful baseline before you start adding third-party origins.

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'; upgrade-insecure-requests

Content Security Policy Generatora strict CSP header in minutes

Delivery

Resource directives

Inline content

Frames, forms, and base URI

Reporting

Generated policy

How to roll out a Content Security Policy safely

CSP directive reference

Three policies to start from

Discovery (Report-Only)

Strict modern policy with strict-dynamic

Same-origin static site

Where CSP fits in a pentest finding

Related tools and resources

Frequently asked questions

What does Content-Security-Policy actually protect against?

Should I start with Content-Security-Policy-Report-Only?

What is the difference between unsafe-inline, unsafe-eval, nonces, and hashes?

Do I need both frame-ancestors and X-Frame-Options?

What does strict-dynamic do?

Will a strict CSP break my site?

Related features

Vulnerability scanning tools that map your attack surface

Vulnerability management software that tracks every finding

AI-powered reports in seconds, not days

Security testing for web applications

Cyber security assessments

Penetration testing

Want to verify the policy after you ship it?

Delivery

Resource directives

Inline content

Frames, forms, and base URI

Reporting

Generated policy

How to roll out a Content Security Policy safely

CSP directive reference

Three policies to start from

Discovery (Report-Only)

Strict modern policy with strict-dynamic

Same-origin static site

Where CSP fits in a pentest finding

Related tools and resources

Frequently asked questions

What does Content-Security-Policy actually protect against?

Should I start with Content-Security-Policy-Report-Only?

What is the difference between unsafe-inline, unsafe-eval, nonces, and hashes?

Do I need both frame-ancestors and X-Frame-Options?

What does strict-dynamic do?

Will a strict CSP break my site?

Content Security Policy Generator
a strict CSP header in minutes