security - What does CSP protect us if allowing unsafe-inline

Question

Currently I'm defining Content Security Policy (CSP) as below;

Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"

Considering the CSP definition above, I have a challenge with inline JavaScript as it can be over-ridden at any time.

What is the use of unsafe-inline if it virtually does not protect?

question from:https://stackoverflow.com/questions/40144915/what-does-csp-protect-us-if-allowing-unsafe-inline

Answer 1

The unsafe-inline option is to be used when moving or rewriting inline code in your current site is not an immediate option but you still want to use CSP to control other aspects (such as object-src, preventing injection of third-party js etc.). You are correct in that unsafe-inline does not offer much security as it allows execution of unsafe in-page scripts and event handlers.

Google's CSP Evaluator is a nifty tool to determine if your policy is strong.

A use case where the unsafe-inline option is used can be found in Google's Web Developer documentation on Content Security Policy:

A wedding-ring discussion forum admin wants to ensure that all resources are only loaded via secure channels, but doesn't really write much code; rewriting large chunks of the third-party forum software that's filled to the brim with inline script and style is beyond his abilities. The following policy would be effective:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Even though https: is specified in default-src, the script and style directives don't automatically inherit that source. Each directive completely overwrites the default for that specific type of resource.