Content Security Policy Sources

Sources are the places where content is allowed to be loaded/executed from. In this policy, 'self' google.com, sha256-abc and https: are all sources.

Source Types

Source	Examples	Description
Host Source	https://example.com/something.js example.com example.com:1337 *.example.com	The host source the most common, and it's very configurable.
Scheme Source	https: wss:	Matches anything with the specified scheme. Useful if you only want to allows https: for example.
Nonce Source	nonce-l0ngr4nd0mt0k3n	CSP can be used in nonce form, where the policy specifies a random nonce per request, and then all script tags must include the nonce. `<script nonce=">alert()</script>`.
Hash Source	sha256-abc123	Can be useful for static javascript. The browser will take the hash of a javascript block and check to see if it matches any sha256-xxx in the policy. Can also be used with sha384 / sha512

Source	Description
'self'	Include resources from the origin the policy was delivered from. Very useful and common keyword
'none'	Don't allow anything for this directive to be loaded.
'unsafe-inline'	The most dangerous thing to happen to content-security-policy. Allows inline resources to be included. For information on why this is so bad, please check out No More Unsafe inline. It should never be used within a script-src.
'unsafe-eval'	Allows the usage of eval, new Function(), and setTimeout/setInterval with strings. Should be avoided if possible.
'report-sample'	When the browser generates a violation report for report-uri, it will include the first 40 characters of the violating payload.
'strict-dynamic'	An advance feature of CSP where trust is propogated through resources. More Info

Technical reference for content security policy directives

Why 'unsafe-inline' negates the primary benefit of content-security-policy, and ways to avoid using 'unsafe-inline'