On a similar topic as CORS and the same origin police I wrote some months ago, there is another initiative called Content Security Policy which is defined as follow in the Mozilla Developper Network CSP Page :
Content Security Policy
(CSP) is an added layer of security that helps to detect and mitigate
certain types of attacks, including Cross Site Scripting (XSS) and data
injection attacks. These attacks are used for everything from data theft
to site defacement or distribution of malware.
idea behind is that you will "whitelist" the code you accept to render
whether it is hosted on third party serivces (like facebook or google
buttons) up to inline code within your page (yes, I mean the CSS and JS
code you add with the <style> and <script> tags)
What does it look like ?
so far only a HTTP Header called "Content-Security-Policy" you will
have to set ; for the 1.1 Specs, it will also be a "meta" tags you can
set in your HTML.
You will define then the diffrent directives you want to have, depending on your needs :
connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource).
font-src specifies the origins that can serve web fonts. Google’s Web Fonts could be enabled via
frame-src lists the origins that can be embedded as frames. For example:
frame-src https://youtube.com would enable embedding YouTube videos, but no other origins.
img-src defines the origins from which images can be loaded.
media-src restricts the origins allowed to deliver video and audio.
object-src allows control over Flash and other plugins.
script-src lists the origin of scripts that would be loaded
script-src’s counterpart for stylesheets.
Let's see an example :
Content-Security-Policy: script-src 'self' https://apis.google.com
It would mean that :
- any script loaded from my domain and from https://apis.google.com will be loaded.
- If you try to load jquery from code.jquery.com in your html, it will not be loaded as this host has not been whitelisted.
Another example to illustrate to what extend you can fine tune this directive :
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; frame-src 'self'
It would mean that :
- You will not load any code hosted on your domain
- Script, Style and Image files can only be loaded fomr https://cdn.mybank.net
- You can connect via Ajax or similar only to https://api.mybank.com/
- and load frame only from your domain
- Outside of this rules, all other code/content will never be loaded.
one, if you want your site to load all the required files for social
widgets (like Facebook, Twiitter, Google ones), the directive would be :
Content-Security-Policy: default-src 'self'; script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
Inline CSS / JS Code
defined "self" as default-src, it will prevent from loading indline
JS/CSS code and also prevent "eval()" to be computed.
the best practice is of course to put your CSS / JS code in external
files. However, if you can't, you will have to add the "unsafe-inline"
and "unsafe-eval" directives. Of course, it's strongly disrecommended. Indeed, if anyone can inject code in your page, then it will do whatever he wants.
Reporting & Monitoring
CSP may hurt your site to some extend as you may forgot to declare
some required resources and of course you may be interested to know if
someone tries to inject code. CSP also provides some directives for
these two needs.
for debug purposes, you have the "report-only" directive that would
report files to be excluded but will not block them ; you will then use :
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
you are fine and go in production, you want to know what happens in
reality and prevent malicious code to be loaded. Just do as follow :
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
both cases, once the rule is hit, the browser will POST the information
to your report uri and you will have something like :
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
Current support in browsers
- Firefox from Firefox 23 (next stable release) and later. Firefox for Android and Firefox OS soon to follow.
- Chrome : 25 and later
- Internet Explorer : 10 and later (sandbox directive only)
How if differs from CORS ?
also aims to mitigate the "same origin policy" issue by allowing which
sites can load your content. CSP is the opposite as you would define
which hosts you want to load content from and will go deeper as it
allows a fine grained control on the loaded/computed code.
I would say CSP it really security focused whereas CORS was more to ease developper tasks to load content from another place.
More resources on CSP
[Edit 1] : An example on how to play safely in sanboxed iframes.