We use the following CSP header:
default-src 'self' *.ourdomain.com; script-src 'self' *.ourdomain.com 'sha256-[...]' 'unsafe-eval';
connect-src 'self' *.ourdomain.com;
style-src 'unsafe-inline' * 'self' data:; font-src *;
img-src * 'self' data:
The recommendation by our security team is not use unsafe-eval.
My question is: as long as we are using sha256-[...] to restrict any script that we haven't deployed ourselves, what is the security risk of still keeping unsafe-eval in the CSP header? In what situation would this still expose us to cross-site attacks?
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".
2022 edit: the section below has not stood the test of time and things like WASM require unsafe-eval. It's still true that many front end frameworks still require unsafe-eval too.
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 (at the time this was written)