ArchivesTagged Articles |
Wednesday, October 24. 2012The current state of CSP implementations?
OK, so I was playing around with Content security policies for a bit. I hacked up a very, very basic example page (you can switch the CSP headers off by ommitting the query string) that sets the following headers:
header(“X-Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”); header(“X-Webkit-CSP: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”); header(“Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’; img-src www.php-security.net; script-src ‘self’ ‘unsafe-inline’; report-uri /report.php”); According to the spec, this should enable the otherwise forbidden execution of inline scripts via tags, allow images to be loaded from php-security.net and scripts only to be loaded from the domain the document resides on (also php-security.net). Safari and Chrome do exactly what I would like them to do, however current release Firefox seems to not have a way to allow inline script, although the policy states otherwise. The report shows: Blocked-URI: self Violated Directive: inline script base restriction Did I implement the policy wrong or is this a bug in Firefox’s interpretation of the spec? Of course it does not make a lot of sense to implement a CSP and still allow inline script execution, but when looking at customer sites, I cannot even begin to imagine the breakage that would be caused by banning et al. So it’s probably a necessity to at least have a reliable possibility to allow inline script execution for now and tighten the requirement later. Trackbacks
Trackback specific URI for this entry
No Trackbacks
|
|
Powered by s9y - Design by Lordcoffee