Content Security Policy is an HTTP header set by the server and enforced by the web browser (client) as a defence against cross-site scripting vulnerabilities. The experimental headers X-Content-Security-Policy and should now be replaced by the standard Content-Security-Policy.
The announcement by Mozilla regarding support for v1.0 in Firefox provided a good overview of recent changes and links to further information resources.
The steps I would recommend to introduce Content Security Policy (CSP) are:
- Choose one pilot web application and a single functional area with greater security assurance requirements (e.g. payment, checkout, order submission, authentication)
- Create a change request for deployment to production and assess the risks
- Create an initial Content-Security-Policy header in development, test locally and apply to staging/test systems
- Undertake existing unit tests for the functional area using the latest, recent and legacy web browsers
- Make changes to code and/or the policy to determine what can be achieved
- Build a mechanism to collect the violation reports, ensuring all data is treated as untrusted and is correctly encoded when utilised, and add a report-uri directive to the header to verify the mechanism
- In production, add the directives as a Content-Security-Policy-Report-Only header to the functional area (i.e. not as a Content-Security-Policy header)
- Monitor and assess the violation reports
- Adjust the policy as necessary and re-test, and re-deploy
- Once approved, change the header from Content-Security-Policy-Report-Only to an enforced Content-Security-Policy header for a test group of users
- Monitor and update the policy as necessary, and re-test/re-deploy
- Gradually extend to all users
- Update coding standards so that future development is compatible with the CSP
- Repeat for other functional areas
- Apply CSP policies to the remainder of the web application (with differing policies as necessary).
This blog's CSP header states the web server wishes the page only loads resources from its own origin over TLS, without frame embedding, but modify the style-src directive to allow inline styles. Thus no unsafe use of inline scripting or eval are disallowed. Also, a URL is specified for CSP violation reports. The header is:
default-src https: 'self'; frame-src 'none'; style-src 'self' 'unsafe-inline'; report-uri https://www.clerkendweller.uk/report-csp.php
I have also noticed some inconsistencies in this inline styles aspect between web browsers, and also in the use of the frame-src directive. It is expected these anomalies will disappear as use of the header broadens and deployment matures. As usual it is necessary to test the use of the header across multiple browser types and versions. There also seems to be an issue with some bookmarking tools and browser extensions causes false positive reports, so use of the report-uri directive can be somewhat noisy in public parts of web applications.
Posted on: 02 July 2013 at 18:55 hrs