CSP Builder & Analyzer

Continue in the tool

Content-Security-Policy and XSS

Content-Security-Policy: The Directives That Actually Stop XSS

A poorly assembled `Content-Security-Policy` header gives a false sense of protection: it exists, it has several directives, but a single word like `unsafe-inline` inside `script-src` hands the attacker back almost all the power XSS had before the policy existed.

The Directives That Decide What the Page Can Load and Run

CSP, specified by the W3C (Content Security Policy Level 3), works as an allowlist: `default-src` sets the fallback origin for anything without its own directive, `script-src` controls where scripts can load from and what they are allowed to do, `style-src` does the same for CSS, and `frame-ancestors` decides who can put the page inside an `<iframe>`, replacing the older `X-Frame-Options` header. A policy like `default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'` already closes four common attack doors without naming a single external domain.
The point most people get wrong is `'unsafe-inline'` in `script-src`: XSS works by injecting a `<script>` tag or an `onclick` attribute straight into the page, and `'unsafe-inline'` allows exactly that kind of script to run, so adding it hands the attacker back nearly all the benefit the policy was supposed to block. The correct path is generating a fresh random nonce on every server response and writing it into both the `<script nonce="...">` tag and the `script-src 'nonce-...'` directive, or using a `'sha256-...'` hash of the exact content of the allowed script; any script that does not match that response's nonce or hash gets blocked, injected or not.
Testing a policy before locking down a production site is possible with the `Content-Security-Policy-Report-Only` header, which applies the same rules but only logs violations instead of blocking, sending reports to the endpoint set in `report-to` (the older `report-uri` still works but is being replaced by the Reporting API). That is how a legitimate script left out of the policy gets discovered before a real user sees the page break.

Two Policies, Seven Findings Apart

Policy with a nonce, nearly clean

Input: default-src 'self'; script-src 'self' 'nonce-r4nd0mB4se64=='; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'
Expected output: 1 achado: unsafe-inline-style (médio); 5 pontos fortes incluindo uses-nonce-hash

`script-src` uses a nonce correctly and is not flagged; the only issue is `'unsafe-inline'` left over in `style-src`, classified as medium severity because injected CSS has less execution power than injected JavaScript.

Wide-open policy, six findings

Input: default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval'
Expected output: 6 achados, 3 de severidade alta: unsafe-inline-script, unsafe-eval, wildcard-source

The `*` wildcard in `default-src` opens every origin for anything without its own directive, and `'unsafe-inline'` plus `'unsafe-eval'` together in `script-src` allow both injected inline script and string-based `eval()`, the two classic XSS execution doors.

The generator's recommended starting point

Input: botão 'política inicial' do gerador
Expected output: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

This baseline deliberately leaves out `script-src` and `style-src`: it forces whoever is publishing the policy to explicitly choose between a nonce, a hash, or a domain list for scripts and styles, instead of inheriting a generic `'self'` that might be more permissive than the site actually needs.

Full tool FAQ

What is Content-Security-Policy?

It is an HTTP header that controls which origins the browser may use for scripts, styles, images, frames and other resources. Its main purpose is to mitigate XSS and content-injection attacks.

Why is 'unsafe-inline' considered weak?

Is the policy sent to any server?

Why should I set object-src, base-uri and frame-ancestors?

What does the wildcard * mean in a directive?

What is the difference between default-src and the specific directives?

Does the tool guarantee my policy is 100% secure?

Can I use the generated policy straight in production?

Frequently asked questions

Does 'unsafe-inline' in script-src really defeat XSS protection?

In practice, yes for the most common vector: most XSS attacks inject a `<script>` tag or an inline event attribute into the page, and `'unsafe-inline'` allows exactly that kind of code to run unrestricted; the policy still blocks scripts from an unlisted external origin, but it loses its defense against the most frequent kind of injection.

What is the practical difference between a nonce and a hash in CSP?

A nonce is a random value the server generates on every response and repeats in both the directive and the script tag, so every page load carries a different nonce; a hash is the result of running SHA-256, SHA-384 or SHA-512 over the exact content of the allowed script, so it works well for fixed inline scripts that do not change per request, with nothing new to generate server-side.

Does Content-Security-Policy-Report-Only block anything?

No. It applies the same rules as the enforcing policy purely for evaluation: anything that would violate the policy still loads and runs normally, but a violation report gets sent to the endpoint configured in `report-to`, which lets a new policy be tested in production without breaking anything before switching over to the real `Content-Security-Policy` header.

Why does object-src 'none' show up in almost every recommended policy?

Because `object-src` controls plugins like `<object>`, `<embed>` and `<applet>`, older technologies like Flash that had their own ways of executing code independent of `script-src`'s rules; locking that directive to `'none'` closes an execution path the rest of the policy cannot even see.

Next steps

Continue in the tool

Open full tool

Content-Security-Policy and XSS

Content-Security-Policy: The Directives That Actually Stop XSS

The Directives That Decide What the Page Can Load and Run

CSP, specified by the W3C (Content Security Policy Level 3), works as an allowlist: `default-src` sets the fallback origin for anything without its own directive, `script-src` controls where scripts can load from and what they are allowed to do, `style-src` does the same for CSS, and `frame-ancestors` decides who can put the page inside an `<iframe>`, replacing the older `X-Frame-Options` header. A policy like `default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'` already closes four common attack doors without naming a single external domain.

The point most people get wrong is `'unsafe-inline'` in `script-src`: XSS works by injecting a `<script>` tag or an `onclick` attribute straight into the page, and `'unsafe-inline'` allows exactly that kind of script to run, so adding it hands the attacker back nearly all the benefit the policy was supposed to block. The correct path is generating a fresh random nonce on every server response and writing it into both the `<script nonce="...">` tag and the `script-src 'nonce-...'` directive, or using a `'sha256-...'` hash of the exact content of the allowed script; any script that does not match that response's nonce or hash gets blocked, injected or not.

Testing a policy before locking down a production site is possible with the `Content-Security-Policy-Report-Only` header, which applies the same rules but only logs violations instead of blocking, sending reports to the endpoint set in `report-to` (the older `report-uri` still works but is being replaced by the Reporting API). That is how a legitimate script left out of the policy gets discovered before a real user sees the page break.

Two Policies, Seven Findings Apart

Policy with a nonce, nearly clean

Input: default-src 'self'; script-src 'self' 'nonce-r4nd0mB4se64=='; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'
Expected output: 1 achado: unsafe-inline-style (médio); 5 pontos fortes incluindo uses-nonce-hash

Wide-open policy, six findings

Input: default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval'
Expected output: 6 achados, 3 de severidade alta: unsafe-inline-script, unsafe-eval, wildcard-source

The generator's recommended starting point

Input: botão 'política inicial' do gerador
Expected output: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Full tool FAQ

What is Content-Security-Policy?

It is an HTTP header that controls which origins the browser may use for scripts, styles, images, frames and other resources. Its main purpose is to mitigate XSS and content-injection attacks.

Why is 'unsafe-inline' considered weak?

Is the policy sent to any server?

Why should I set object-src, base-uri and frame-ancestors?

What does the wildcard * mean in a directive?

What is the difference between default-src and the specific directives?

Does the tool guarantee my policy is 100% secure?

Can I use the generated policy straight in production?

Frequently asked questions