Content-Security-Policy
Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client browser about expected behavior of the application (including content sources, script sources, plugin types, and other remote resources), which allows the browser to more intelligently enforce security constraints. A well-applied Content Security Policy essentially eliminates most forms of Cross Site Scripting attacks.
How does this work?
A web application declares where it expects to load scripts, allowing the client to detect and block malicious scripts injected into the application by an attacker.
Another way to think about content-security policy is as a source whitelist. Typically when we make a request for a web page, our browsers trusts output that the server is delivering. CSP limits this trust model by sending Content-Security-Policy header that allows the application to specify a whitelist of trusted (expected) sources. When the browser receives this header, it will only render or execute resources from those sources.
In the event that an attacker does have the ability to inject malicious content that is reflected back against the user, the script will not match the whitelist, and will not be executed.
Why would I want this?
This is an effective way to mitigate Cross-site scripting (XSS). Traditional mechanisms to mitigate cross-site scripting are to HTML encode or escape output that is reflected back to a user as well as perform rigorous input validation. However due to the complexity of encoding and validation, cross-site scripting may crop up in your website.
Content-security policy is not a replacement for this strategy!
What content-security policy does is provide a solid defense in depth strategy, to reduce the harm caused by content injection attacks.
Okay I’m sold, show me some examples!
Let’s look at some examples that can be found in the Content Security Policy 1.1 W3C Working Draft
Example 1: A server wishes to load resources only from its own origin:
Content-Security-Policy: default-src 'self'Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:
Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.comExample 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'Example 4: A website that relies on inline script elements wishes to ensure that script is only executed from its own origin, and those elements it intentionally inserted inline:
Content-Security-Policy: script-src 'self' 'nonce-$RANDOM';The inline script elements would then only execute if they contained a matching nonce attribute:
<script nonce="$RANDOM">...</script>Now that you’ve got the idea, check out How to Use this site, or jump straight the interactive Violation Examples and the equivalent but CSP-friendly Compliant Examples.