Nytro Posted January 26, 2014 Report Posted January 26, 2014 4 HTTP Security headers you should always be using23-01-2014 Boy Baukema What started as a dream for a worldwide library of sorts, has transformed into not only a global repository of knowledge but also the most popular and widely deployed Application Platform: the World Wide Web. The poster child for Agile, it was not developed as a whole by a single entity, but rather grew as servers and clients expanded it's capabilities. Standards grew along with them. While growing a solution works very well for discovering what works and what doesn't, it hardly leads to a consistent and easy to apply programming model. This is especially true for security: where ideally the simplest thing that works is also the most secure, it is far too easy to introduce vulnerabilities like XSS, CSRF or Clickjacking. Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system. 1. Content-Security-Policy What's so good about it? How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it? That's the promise of Content-Security-Policy. Adding the Content-Security-Policy header with the appropriate value allows you to restrict the origin of the following: script-src: JavaScript code (biggest reason to use this header) connect-src: XMLHttpRequest, WebSockets, and EventSource. font-src: fonts frame-src: frame ulrs img-src: images media-src: audio & video object-src: Flash (and other plugins) style-src: CSS So specifying the following:Content-Security-Policy: script-src 'self' https://apis.google.comMeans that script files may only come from the current domain or from apis.google.com (the Google JavaScript CDN). Another helpful feature is that you can automatically enable sandbox mode for all iframes on your site. And if you want to test the waters, you can use use the 'Content-Security-Policy-Report-Only' header to do a dry run of your policy and have the browser post the results to a URL of your choosing. It is definitely worth the time to read the excellent HTML5Rocks introduction.Articol complet:http://ibuildings.nl/blog/2013/03/4-http-security-headers-you-should-always-be-using Quote
