Does the design and implementation of the content security policy standard allow for the introduction of new unsafe behavior that wasn't there prior to having any CSP at all?
For example if my starting point is having no CSP headers or policy at all and I then introduce a CSP which contains:
Is it now less secure (e.g. has it enabled something that was not allowed prior to having any CSP)?
The goal of Content-Security-Policy is to add an additional security layer and not relax existing security settings. From Content Security Policy Level 3 - Introduction:
... use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
So CSP cannot be used to relax the Same Origin Policy. That would be CORS instead.
As for your example of unsafe-inline and unsafe-eval: With no CSP these are enabled by default. So a CSP which has these directives does not relax the existing default security settings.
No CSP means no restrictions. Any CSP is better than no CSP.
I like to read a CSP directive img-src ___ or frame-src ___ out loud as "images/frames are not allowed except from ___".
So this CSP:
Content-Security-Policy: img-src https://example.com
would be read out loud as "images are not allowed except for from https://example.com". What about frames? They are not specified, therefore they are allowed. Typically a page will set a CSP will set a very restrictive default-src and then specifically override that to allow the external resources that it needs.
Content-Security-Policy: default-src 'self'; img-src https://example.com
which I read out loud as "Things are only allowed from self, except for images which are not allowed except for from https://example.com"
If a CSP directive (ex.: frame-src) is not specified (and default-src is also not specified) then no restrictions are applied.
That means that no CSP is equivalent to an empty CSP where everything is allowed (nothing is blocked).
