The standard, originally named Content Restrictions, was proposed by Robert Hansen in 2004, first implemented in Firefox 4 and quickly picked up by other browsers. Version 1 of the standard was published in 2012 as W3C candidate recommendation and quickly with further versions (Level 2) published in 2014. As of 2015 draft of Level 3 is being developed with the new features being quickly adopted by the web browsers.
The following header names are in use as part of experimental CSP implementations:
Content-Security-Policy- standard header name proposed by the W3C document. Google Chrome supports this as of version 25. Firefox supports this as of version 23, released on 6 August 2013.WebKit supports this as of version 528 (nightly build).
X-WebKit-CSP- deprecated, experimental header introduced into Google Chrome and other WebKit-based browsers (Safari) in 2011.
X-Content-Security-Policy- deprecated, experimental header introduced in Gecko 2 based browsers (Firefox 4 to Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).
A website can declare multiple CSP headers, also mixing enforcement and report-only ones. Each header will be processed separately by the browser.
A number of web application frameworks support CSP, for example AngularJS (natively) and Django (middleware). Instructions for Ruby on Rails have been posted by GitHub. Web framework support is however only required if the CSP contents somehow depend on the web application's state--such as usage of the
nonce origin. Otherwise, the CSP is rather static and can be delivered from web application tiers above the application, for example on load balancer or web server.
As of 2015a number of new browser security standards are being proposed by W3C, most of them complementary to CSP:
In December 2015 and December 2016, a few methods of bypassing
styleattributed to HTML elements
<script src>), parse JSON instead of evaluating it and use
EventTarget.addEventListener to set event handlers.
<style>blocks can individually whitelisted in the CSP using
<html ng-app ng-csp>
According to the original CSP (1.0) Processing Model (2012-2013), CSP should not interfere with the operation of browser add-ons or extensions installed by the user. This feature of CSP would have effectively allowed any add-on, extension, or Bookmarklet to inject script into web sites, regardless of the origin of that script, and thus be exempt to CSP policies.
However, this policy has since been modified (as of CSP 1.1) with the following wording. Note the use of the word "may" instead of the prior absolute "should (not)" wording:
Note: User agents may allow users to modify or bypass policy enforcement through user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms.
The absolute "should" wording was being used by browser users to request/demand adherence to the policy and have changes installed in popular browsers (Firefox, Chrome, Safari) to support it. This was particularly contentious when sites like Twitter and GitHub started using strong CSP policies, which 'broke' the use of Bookmarklets.
The W3C Web Application Security Working Group considers such script to be part of the Trusted Computing Base implemented by the browser; however, it has been argued to the working group by a representative of Cox Communications that this exemption is a potential security hole that could be exploited by malicious or compromised add-ons or extensions.
Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection.
Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous.
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your IT knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.