We use the following CSP header:
default-src \'self\' *.ourdomain.com; script-src \'self\' *.ourdomain.com \'sha256-[...]\' \'unsafe-eval\';
connect-src \'self
The security risk is that it doesn't protect any of your own code that may be vulnerable because eval
is used.
If you are using eval
in your own code you should question why. Is there a safer alternative that can be employed instead?
See here for a (contrived) example of how code can be injected by an attacker. Of course whether this can be done to your site very much depends on your code.
The upshot is that there's almost always an alternative to using eval
.
Because eval is literally unsafe. Eval in every language means "take this string and execute it code." Sure, you may be using eval in a semi-safe way, but as long as you allow it at all, you are saying "anyone is allowed to execute arbitrary code in my application given an entry point".
It is my opinion that there is no reason to use eval. Show me a case where eval is required in actual useful code and I'll bet that I can rewrite the code without using eval or declare it as impossibly secure code.
Disallowing Inline script is only half the battle, especially if you use jquery.
Quiz: does this code trigger an inline script violation or an eval violation?
$('body').html('<script>alert(1)</script>')
You may be surprised.
Spoiler:
it's eval