3

I am reviewing the Content-Security-Policy headers set in one of our webservers and I see this is how it is set (where 'example.com' is our trusted website).

Content-Security-Policy: "default-src 'self'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval'; img-src 'self' *.example.com; font-src *; connect-src 'self' *example.com"

My questions are:

1) Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP?

2) If 'unsafe-inline' is allowed or whitelisted as above, can someone call a JavaScript from an external website, say www.xxxxxx.com that is not whitelisted in script-src directive and there-by defeat the whole purpose of CSP? Eg: <script src="www.xxxxxx.com/bad.js">

I went through this question here and going by the answers, it does look like the above CSP is not good.

Improve this question

2 Answers 2

Reset to default
6

Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP?

Yes. A tight CSP will make it harder to exploit XSS by restricting the scripts that can be executed. Using unsafe-inline and unsafe-eval allow to run any script. This is also why they are prefixed by unsafe-, to discourage you from using them in the CSP.

Of course the data: protocol also makes it possible to bypass the CSP, since you can encode any script as data: URL.

If 'unsafe-inline' is allowed or whitelisted as above, can someone call a JavaScript from an external website

You could retrieve the script contents and run them from within JavaScript. Including it with <script src="www.xxxxxx.com/bad.js"> doesn't work but since you can run JavaScript anyway there are other ways to run external script.

Improve this answer
2
  • Thank you. So, this CSP does prevent calling JavaScripts from external websites, that way it does help in making the webpage more secure that not having this CSP?
    – Sreeraj
    Nov 20, 2018 at 12:25
  • 2
    If you have your front door wide open, does locking your back door make things "more secure"?
    – Sjoerd
    Nov 20, 2018 at 12:34
0

Sjoerd covered what are (in my opinion) the major points on this topic, but I’d like to add that allowing inline JavaScript doesn’t fully make CSP worthless here. There is still a point to using a well-written Content Security Policy outside the boundaries of avoiding XSS.

As we’re all aware, CSP is a deeply powerful tool. While the bulk of its power dwells in making it easier to defend against XSS and its friends, it also has a number of functionalities that remain valuable even once you disable the XSS-specific features and open up that vector. These include:

  • Features tangential to preventing XSS, like the sandbox directive
  • Independent features, like the upgrade-insecure-requests directive
  • Supporting features that can be deeply leveraged on their own, like
    the reporting capabilities

In case it’s useful, Mozilla has an excellent write-up of CSP’s features here.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .