Content Security Policy (CSP) was proposed to assist the browser in determining what elements are approved, both in the page and loaded via reference to 3rd party sites. For example, one of the web’s most common vulnerabilities is Cross-Site Scripting (XSS).
Perhaps the most useful feature of CSP is the ability to operate it in report-only mode, which sends any potential violations to a specified URI without blocking functionality. This is the best way to get started with CSP. Once you are comfortable with the policy and white-list of sources you can switch off the report-only mode and violations which would normally result in an XSS attack would be blocked. Each of these violations causes a report to be sent, incurring a small browser performance hit that can add up fast. We’ll cover several of these types of problem cases in Part 2 for this series.
So what’s driving the adoption of Content Security Policy?
There are 3 reasons to start CSP
So what type of minimal, yet permissive policy might you start with?
Content-Security-Policy-Report-Only: script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ https:; object-src ‘self’ https:; report-uri /mycspreportcollector
If this does not produce any reports you can start by removing ‘https:’ from object-src then script-src to identify what domains you must add back, and so on.
The following resources give a supplementary overview of CSP:
This is the first post of a 3-part series written by Garrett Held.