Discuss your project

TOOLBOX · TOOL

Check and Build CSP.

Paste a Content Security Policy and have it rated, or create a new one from templates. With a ready-made configuration for your server. Runs only in your browser.

Header value, a line “Content-Security-Policy: …”, a line from nginx or Apache, or a <meta> tag. The analysis runs entirely in your browser: your policy does not leave the device and is not stored anywhere.

Only in your browser: this tool sends nothing to TOMORIS or third parties. Check your website’s headers

HOW TO ROLL OUT THE CSP

Observe First.
Then Enforce.

A CSP that blocks your own content is quickly removed again. With Report-Only you see beforehand what the policy would block.

  1. 01

    Choose a Template

    Pick the template closest to your website and adapt the directives to your sources.

  2. 02

    Deliver as Report-Only

    Set the Content-Security-Policy-Report-Only header. The browser reports violations in the console and, if entered, to your reporting address.

  3. 03

    Evaluate the Reports

    Add missing sources of your own, check unexpected sources. Allow inline scripts with a nonce or hash.

  4. 04

    Enforce

    Deliver the same policy as Content-Security-Policy and verify it with the security header check.

BASICS

Checked Against
Open Rules.

The rating follows published rules. Templates with third-party services only name the hosts from the vendor’s documentation.

QUESTIONS

Good to Know.

What is a Content Security Policy?

A Content Security Policy (CSP) is an instruction from your server to the browser about which sources a page may load scripts, styles, images and other content from. Injected code from other sources is blocked. This makes the CSP the most important additional protection against cross-site scripting (XSS).

Is my policy transferred to TOMORIS?

No. Analysis and generator run entirely in your browser. The page sends your input nowhere and does not store it.

Which rules is the rating based on?

On the W3C specification Content Security Policy Level 3 and the checks of the Google CSP Evaluator: among others 'unsafe-inline', 'unsafe-eval', wildcards such as * or https: in script-src, the effect of 'strict-dynamic', the format of nonce and hash, missing object-src, base-uri, frame-ancestors and form-action, and typos. The analysis shares the basic rules with the security header check; beyond that it detects subtleties such as invalid nonces or wildcards of the form https://*.

Why test as Report-Only first?

A policy that is too narrow also blocks your own scripts, fonts or analytics calls. In Content-Security-Policy-Report-Only mode, the browser only reports violations but blocks nothing. Only when no more unexpected reports come in do you enforce the same policy as Content-Security-Policy.

Header or meta tag?

The HTTP header is the recommended way. In the meta tag, frame-ancestors, report-uri and sandbox have no effect, and Report-Only is not supported there at all. The meta tag is a stopgap if you cannot set headers.

What does 'strict-dynamic' do?

With 'strict-dynamic', scripts that carry a valid nonce or hash may load further scripts. Browsers then ignore hosts, schemes such as https:, 'self' and 'unsafe-inline'. The policy thus no longer depends on lists of allowed servers, which can often be bypassed.

TOOLBOX

More
Tools.

YOUR NEXT STEP

You Have the Result.
What Comes Next?

We assess findings, prioritize by risk and put changes into practice on request: as a project with EXPERTS or as ongoing operations with GRID.

Discuss the Result