Content Security Policy (CSP)
Quick Reference Guide

The unsafe-inline Source List Keyword

The unsafe-inline Content Security Policy (CSP) keyword allows the execution of inline scripts or styles.


Except for one very specific case, you should avoid using the unsafe-inline keyword in your CSP policy. As you might guess it is generally unsafe to use unsafe-inline.

The unsafe-inline keyword annuls most of the security benefits that Content-Security-Policy provide.

What should you use instead of unsafe-inline?

When you want to allow inline scripts or styles on a page that uses CSP, there two much better options: nonce or hash.

When is it ok to use unsafe-inline?

It is only ok to use unsafe-inline when it is combined with the strict-dynamic directive. On browsers that support strict-dynamic (CSP Level 3+), the unsafe-inline is ignored, and provides a route to backwards compatibility on browsers that support CSP Level 2 or lower.

In other words, you should only use it if you really know what you are doing!

Why is unsafe-inline not working?

The most common reason that unsafe inline is not working is that you forgot to wrap it with single quotes. It should be specified as: 'unsafe-inline'

Browser Support for unsafe-inline

CSP Level 1

Supported On:

Chrome 25+ (2013)
Firefox 23+ (2013)
Safari 7+ (2013)
Edge 12+ (2015)

Not Supported On:

Internet Explorer

The CSP unsafe-inline source list keyword has been part of the Content Security Policy Specification since the first version of it (CSP Level 1).

Internet Explorer 11 and below do not support the unsafe-inline directive. This means that IE11 will simply ignore the policy and allows the execution of script or css as if no policy existed.