More Proof We Don’t Control Our Web Pages

I’ve talked about this before: As web designers, we can’t trust the network. Sure, we have to contend with mobile data “dead zones” and dropped connections as our users move about throughout the day, but there’s a lot more to the network that’s beyond our control.

Here’s a roundup of some of my “favorite” network issue related headlines from the last few years:

Some of these issues can be avoided by serving content over HTTPS, but that still won’t enable you to bypass things like firewall blacklists (which led to the jQuery outage on Sky). Your best bet is to design defensively and make sure your users can still accomplish their goals on your site when some resources are missing or markup is altered.

We can’t control what happens to us in this world, we can only control our reaction to it.

[{"type":"entry","author":{"type":"card","name":"Aaron Gustafson","photo":null,"url":"https://www.aaron-gustafson.com/about"},"url":"https://www.aaron-gustafson.com/notebook/moved-to-https/","published":null,"wm-received":"2015-09-03T20:42:30Z","wm-id":96899,"wm-source":"https://www.aaron-gustafson.com/notebook/moved-to-https/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"WebOverhauls.com","photo":"https://webmention.io/avatar/twitter.com/e34fa692b1812aead41eb9bab0eec182300f1956699b7063ffa629c1e83a81cb.jpeg","url":"http://www.weboverhauls.com/"},"url":"https://twitter.com/weboverhauls/status/640697741060866048","published":"2015-09-07T01:26:59","wm-received":"2015-09-07T01:35:08Z","wm-id":98921,"wm-source":"https://brid-gy.appspot.com/repost/twitter/AaronGustafson/639160156073426944/640697741060866048","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"reposts this.","content":{"content-type":"text/html","value":"RT <a href=\"https://twitter.com/AaronGustafson\" rel=\"nofollow\">@AaronGustafson</a>: More Proof We Don’t Control Our Web Pages aaron-gustafson.com/notebook/more-…","html":"RT <a href=\"https://twitter.com/AaronGustafson\" rel=\"nofollow\">@AaronGustafson</a>: More Proof We Don’t Control Our Web Pages aaron-gustafson.com/notebook/more-…","text":null},"repost-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"repost-of","wm-private":false},{"type":"entry","author":{"type":"card","name":null,"photo":null,"url":null},"url":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","published":"2015-09-14T22:21:10","wm-received":"2015-09-14T21:22:33Z","wm-id":104001,"wm-source":"https://adactio.com/links/9516","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson","content":{"content-type":"text/html","value":" \n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">\nMore Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson\n</a>\n \n \n<time datetime=\"2015-09-14T22:21:10\">\nSeptember 14th, 2015\n</time>\n \n\n<p>Aaron collects some recent examples that demonstrate</p>\n\n<ol>\n<li>why we should use HTTPS and</li>\n<li>why we should use progressive enhancement.</li>\n</ol>","html":" \n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">\nMore Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson\n</a>\n \n \n<time datetime=\"2015-09-14T22:21:10\">\nSeptember 14th, 2015\n</time>\n \n\n<p>Aaron collects some recent examples that demonstrate</p>\n\n<ol>\n<li>why we should use HTTPS and</li>\n<li>why we should use progressive enhancement.</li>\n</ol>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"AgencyofSocialMedia","photo":"https://webmention.io/avatar/twitter.com/a50309e2b40eb2c0be3aad2d37f34a83408c40d48a9a8b0b5189ba28cf08ce9d.jpeg","url":"https://twitter.com/AgencyofM"},"url":"https://twitter.com/AaronGustafson/status/639160156073426944","published":null,"wm-received":"2015-09-19T10:28:10Z","wm-id":106998,"wm-source":"https://brid-gy.appspot.com/like/twitter/AaronGustafson/639160156073426944/3360908472","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"likes this.","like-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"like-of","wm-private":false},{"type":"entry","author":{"type":"card","name":null,"photo":null,"url":null},"url":"http://aarontgrogg.com/blog/2015/09/23/todays-readings-305/","published":null,"wm-received":"2015-09-23T04:00:59Z","wm-id":109454,"wm-source":"http://aarontgrogg.com/blog/2015/09/23/todays-readings-305/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Steve Barnett","photo":"https://webmention.io/avatar/twitter.com/0526379c8e7ce9912388d39e7394627e8dc98397982108c4f3ae6d3425870433.jpeg","url":"http://naga.co.za/"},"url":"https://twitter.com/maxbarners/status/643695803832397824","published":"2015-09-15T08:00:13","wm-received":"2015-09-23T19:30:58Z","wm-id":110130,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/643695803832397824","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"<3 @AaronGustafson. \"We can’t control what happens to us in this world, we can only control our reaction to it.\" aaron-gustafson.com/notebook/more-…","content":{"content-type":"text/html","value":"&lt;3 <a href=\"https://twitter.com/AaronGustafson\" rel=\"nofollow\">@AaronGustafson</a>. \"We can’t control what happens to us in this world, we can only control our reaction to it.\" <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","html":"&lt;3 <a href=\"https://twitter.com/AaronGustafson\" rel=\"nofollow\">@AaronGustafson</a>. \"We can’t control what happens to us in this world, we can only control our reaction to it.\" <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Baldur Bjarnason","photo":"https://webmention.io/avatar/twitter.com/f2791c22ce91d5d90c1443c20b71720c6616f50207f8156207bc83c1332544ab.png","url":"https://www.baldurbjarnason.com/"},"url":"https://twitter.com/fakebaldur/status/645181349612097536","published":"2015-09-19T10:23:15","wm-received":"2015-09-23T19:31:00Z","wm-id":110131,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/645181349612097536","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"And this is from aaron-gustafson.com/notebook/more-…","content":{"content-type":"text/html","value":"And this is from <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","html":"And this is from <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","text":null},"in-reply-to":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"in-reply-to","wm-private":false},{"type":"entry","author":{"type":"card","name":"Jan Skovgaard","photo":"https://webmention.io/avatar/twitter.com/4e9c19e70e7f7a51578de8d5ca84ba8120a3d833b3792724bbd2c2e0994725f6.jpeg","url":"http://www.batjan.com/"},"url":"https://twitter.com/TheRealBatJan/status/643648821176717312","published":"2015-09-15T04:53:32","wm-received":"2015-09-23T19:31:02Z","wm-id":110132,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/643648821176717312","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"RT @adactioLinks: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson ift.tt/1VYtn1F","content":{"content-type":"text/html","value":"RT <a href=\"https://twitter.com/adactioLinks\" rel=\"nofollow\">@adactioLinks</a>: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","html":"RT <a href=\"https://twitter.com/adactioLinks\" rel=\"nofollow\">@adactioLinks</a>: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Mads Jørgensen","photo":"https://webmention.io/avatar/twitter.com/400a8f64354705bd9022919749a52587cafafd3d88e7c0fc24052b1b058aa25d.jpeg","url":"https://twitter.com/madjor5"},"url":"https://twitter.com/madjor5/status/643654067420569600","published":"2015-09-15T05:14:22","wm-received":"2015-09-23T19:31:05Z","wm-id":110133,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/643654067420569600","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"RT @adactioLinks: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson ift.tt/1VYtn1F","content":{"content-type":"text/html","value":"RT <a href=\"https://twitter.com/adactioLinks\" rel=\"nofollow\">@adactioLinks</a>: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","html":"RT <a href=\"https://twitter.com/adactioLinks\" rel=\"nofollow\">@adactioLinks</a>: More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Adactio Links","photo":"https://webmention.io/avatar/twitter.com/8e0a805eae6791b05c23541931a123a5446393bb9929fcdd274f7e5c33d7792f.jpeg","url":"http://adactio.com/links"},"url":"https://twitter.com/adactioLinks/status/643540209985044481","published":"2015-09-14T21:41:57","wm-received":"2015-09-23T19:31:07Z","wm-id":110134,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/643540209985044481","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson ift.tt/1VYtn1F","content":{"content-type":"text/html","value":"More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","html":"More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson <a href=\"http://ift.tt/1VYtn1F\" rel=\"nofollow\">ift.tt/1VYtn1F</a>\n<a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\"></a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Meredith Case","photo":"https://webmention.io/avatar/twitter.com/06ba86abacc41725f3042179cf06ba55eb6996297c42911a7eee859a8b868192.jpeg","url":"http://meredithcase.com/"},"url":"https://twitter.com/goldieashe/status/645185669644595200","published":"2015-09-19T10:40:25","wm-received":"2015-09-23T19:31:09Z","wm-id":110135,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/645185669644595200","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"\"More Proof We Don’t Control Our Web Pages\" aaron-gustafson.com/notebook/more-…","content":{"content-type":"text/html","value":"\"More Proof We Don’t Control Our Web Pages\" <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","html":"\"More Proof We Don’t Control Our Web Pages\" <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Melanie Richards","photo":"https://webmention.io/avatar/twitter.com/7dd65f7a7b6261486adc51a39028d6c58fe631727960868e7d8b7aa0685d992e.jpeg","url":"http://melanie-richards.com/"},"url":"https://twitter.com/somelaniesaid/status/647615057325457408","published":"2015-09-26T03:33:56","wm-received":"2015-09-26T04:05:58Z","wm-id":111592,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/647615057325457408","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"Conclusion: everyone is awful aaron-gustafson.com/notebook/more-…","content":{"content-type":"text/html","value":"Conclusion: everyone is awful <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","html":"Conclusion: everyone is awful <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"Magnus Leo","photo":"https://webmention.io/avatar/twitter.com/4462b63a90c281500031dbf39ce15062b251c24a6dfb1e18fe51bd2ec5841280.png","url":"http://magnusleo.com/"},"url":"https://twitter.com/leoillustratus/status/647673477558857728","published":"2015-09-26T07:26:04","wm-received":"2015-09-26T07:48:32Z","wm-id":111722,"wm-source":"https://brid-gy.appspot.com/post/twitter/AaronGustafson/647673477558857728","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"RT @somelaniesaid: Conclusion: everyone is awful aaron-gustafson.com/notebook/more-…","content":{"content-type":"text/html","value":"RT <a href=\"https://twitter.com/somelaniesaid\" rel=\"nofollow\">@somelaniesaid</a>: Conclusion: everyone is awful <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","html":"RT <a href=\"https://twitter.com/somelaniesaid\" rel=\"nofollow\">@somelaniesaid</a>: Conclusion: everyone is awful <a href=\"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/\" rel=\"nofollow\">aaron-gustafson.com/notebook/more-…</a>","text":null},"mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":null,"photo":null,"url":null},"url":"http://www.stillbreathing.co.uk/2015/09/15/wednesday-is-link-day-3","published":null,"wm-received":"2015-11-15T00:58:18Z","wm-id":145735,"wm-source":"http://www.stillbreathing.co.uk/2015/09/15/wednesday-is-link-day-3","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T11:19:42Z","wm-id":377598,"wm-source":"https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"Content Security Policy, Your Future Best Friend\n\t \n\n\t\t\t\nBy Nicolas Hoffmann \n\t\t\t\tSeptember 12th, 2016 \n\t\t\t\tCSSJavaScriptSecurity \n\t\t0 Comments  \n\t\t \n\t \n \n\n\tA long time ago, my personal website was attacked. I do not know how it happened, but it happened. Fortunately, the damage from the attack was quite minor: A piece of JavaScript was inserted at the bottom of some pages. I updated the FTP and other credentials, cleaned up some files, and that was that. \nOne point made me mad: At the time, there was no simple solution that could have informed me there was a problem and — more importantly — that could have protected the website’s visitors from this annoying piece of code. \nA solution exists now, and it is a technology that succeeds in both roles. Its name is content security policy (CSP). \nWhat Is A CSP? Link \nThe idea is quite simple: By sending a CSP header from a website, you are telling the browser what it is authorized to execute and what it is authorized to block. \nHere is an example with PHP: \n<?php\r\n    header(\"Content-Security-Policy: <your directives>\");\r\n?>\r\n \nSome Directives Link \nYou may define global rules or define rules related to a type of asset: \ndefault-src 'self' ;\r\n     # self = same port, same domain name, same protocol => OK\r\n \nThe base argument is default-src: If no directive is defined for a type of asset, then the browser will use this value. \nscript-src 'self' www.google-analytics.com ;\r\n     # JS files on these domains => OK\r\n \nIn this example, we’ve authorized the domain name www.google-analytics.com as a source of JavaScript files to use on our website. We’ve added the keyword 'self'; if we redefined the directive script-src with another rule, it would override default-src rules. \nIf no scheme or port is specified, then it enforces the same scheme or port from the current page. This prevents mixed content. If the page is https://example.com, then you wouldn’t be able to load http://www.google-analytics.com/file.js because it would be blocked (the scheme wouldn’t match). However, there is an exception to allow a scheme upgrade. If http://example.com tries to load https://www.google-analytics.com/file.js, then the scheme or port would be allowed to change to facilitate the scheme upgrade. \nstyle-src 'self' data: ;\r\n     # Data-Uri in a CSS => OK\r\n \nIn this example, the keyword data: authorizes embedded content in CSS files. \nUnder the CSP level 1 specification, you may also define rules for the following: \nimg-src\n\nvalid sources of images \nconnect-src\n\napplies to XMLHttpRequest (AJAX), WebSocket or EventSource \nfont-src\n\nvalid sources of fonts \nobject-src\n\nvalid sources of plugins (for example, <object>, <embed>, <applet>) \nmedia-src\n\nvalid sources of <audio> and <video> \n CSP level 2 rules include the following: \nchild-src\n\nvalid sources of web workers and elements such as <frame> and <iframe> (this replaces the deprecated frame-src from CSP level 1) \nform-action\n\nvalid sources that can be used as an HTML <form> action \nframe-ancestors\n\nvalid sources for embedding the resource using <frame>, <iframe>, <object>, <embed> or <applet>. \nupgrade-insecure-requests\n\ninstructs user agents to rewrite URL schemes, changing HTTP to HTTPS (for websites with a lot of old URLs that need to be rewritten). \n For better backwards-compatibility with deprecated properties, you may simply copy the contents of the actual directive and duplicate them in the deprecated one. For example, you may copy the contents of child-src and duplicate them in frame-src. \nCSP 2 allows you to whitelist paths (CSP 1 allows only domains to be whitelisted). So, rather than whitelisting all of www.foo.com, you could whitelist www.foo.com/some/folder to restrict it further. This does require CSP 2 support in the browser, but it is obviously more secure. \nAn Example Link \nI made a simple example for the Paris Web 2015 conference, where I presented a talk entitled “CSP in Action1.” \nWithout CSP, the page would look like this: \nThis page without CSP, ugly and defaced2\nView large version3  Not very nice. What if we enabled the following CSP directives? \n<?php\r\n    header(\"Content-Security-Policy: \r\n      default-src 'self' ;\r\n      script-src 'self' www.google-analytics.com stats.g.doubleclick.net ; \r\n      style-src 'self' data: ;\r\n      img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;\r\n      frame-src 'self' ;\");\r\n?>\r\n \nWhat would the browser do? It would (very strictly) apply these directives under the primary rule of CSP, which is that anything not authorized in a CSP directive will be blocked (“blocked” meaning not executed, not displayed and not used by the website). \nBy default in CSP, inline scripts and styles are not authorized, which means that every <script>, onclick or style attribute will be blocked. You could authorize inline CSS with style-src 'unsafe-inline' ;. \nIn a modern browser with CSP support, the example would look like this: \nThis page with CSP, really better4\nView large version5  What happened? The browser applied the directives and rejected anything that was not authorized. It sent these notifications to the console: \nCSP notifications6\nView large version7  If you’re still not convinced of the value of CSP, have a look at Aaron Gustafson’s article “More Proof We Don’t Control Our Web Pages8.” \nOf course, you may use stricter directives than the ones in the example provided above: \nset default-src to 'none', \nspecify what you need for each rule, \nspecify the exact paths of required files, \netc. \n More Information On CSP Link \nSupport Link \nCSP is not a nightly feature requiring three flags to be activated in order for it to work. CSP levels 1 and 2 are candidate recommendations! Browser support for CSP level 19 is excellent. \nCSP Level 1 support on Can I Use10\nView large version11  The level 2 specification is more recent12, so it is a bit less supported. \nCSP Level 2 support on Can I Use13\nView large version14  CSP level 3 is an early draft now, so it is not yet supported, but you can already do great things with levels 1 and 2. \nOther Considerations Link \nCSP has been designed to reduce cross-site scripting (XSS) risks, which is why enabling inline scripts in script-src directives is not recommended. Firefox illustrates this issue very nicely: In the browser, hit Shift + F2 and type security csp, and it will show you directives and advice. For example, here it is used on Twitter’s website: \nCSP display on Firefox15\nView large version16  Another possibility for inline scripts or inline styles, if you really have to use them, is to create a hash value. For example, suppose you need to have this inline script: \n<script>alert('Hello, world.');</script>\r\n\r\n \nYou might add 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=' as a valid source in your script-src directives. The hash generated is the result of this in PHP: \n<?php\r\n    echo base64_encode(hash('sha256', \"alert('Hello, world.');\", true));\r\n?>\r\n \nI said earlier that CSP is designed to reduce XSS risks — I could have added, “… and reduce the risks of unsolicited content.” With CSP, you have to know where your sources of content are and what they are doing on your front end (inline styles, etc.). CSP can also help you force contributors, developers and others to respect your rules about sources of content! \nNow your question is, “OK, this is great, but how do we use it in a production environment?” \nHow To Use It In The Real World Link \nThe easiest way to get discouraged with using CSP the first time is to test it in a live environment, thinking, “This will be easy. My code is bad ass and perfectly clean.” Don’t do this. I did it. It’s stupid, trust me. \nAs I explained, CSP directives are activated with a CSP header — there is no middle ground. You are the weak link here. You might forget to authorize something or forget a piece of code on your website. CSP will not forgive your oversight. However, two features of CSP greatly simplify this problem. \nreport-uri Link \nRemember the notifications that CSP sends to the console? The directive report-uri can be used to tell the browser to send them to the specified address. Reports are sent in JSON format. \nreport-uri /csp-parser.php ;\r\n \nSo, in the csp-parser.php file, we can process the data sent by the browser. Here is the most basic example in PHP: \n$data = file_get_contents('php://input');\r\n\r\n    if ($data = json_decode($data, true)) {\r\n     $data = json_encode(\r\n      $data,\r\n      JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES\r\n      );\r\n     mail(EMAIL, SUBJECT, $data);\r\n    }\r\n \nThis notification will be transformed into an email. During development, you might not need anything more complex than this. \nFor a production environment (or a more visited development environment), you’d better use a way other than email to collect information, because there is no auth or rate limiting on the endpoint, and CSP can be very noisy. Just imagine a page that generates 100 CSP notifications (for example, a script that display images from an unauthorized source) and that is viewed 100 times a day — you could get 10,000 notifications a day! \nA service such as report-uri.io17 can be used to simplify the management of reporting. You can see other simple examples for report-uri18 (with a database, with some optimizations, etc.) on GitHub. \nreport-only Link \nAs we have seen, the biggest issue is that there is no middle ground between CSP being enabled and disabled. However, a feature named report-only sends a slightly different header: \n<?php\r\n    header(\"Content-Security-Policy-Report-Only: <your directives>\");\r\n?>\r\n \nBasically, this tells the browser, “Act as if these CSP directives were being applied, but do not block anything. Just send me the notifications.” It is a great way to test directives without the risk of blocking any required assets. \nWith report-only and report-uri, you can test CSP directives with no risk, and you can monitor in real time everything CSP-related on a website. These two features are really powerful for deploying and maintaining CSP! \nConclusion Link \nWhy CSP Is Cool Link \nCSP is most important for your users: They don’t have to suffer any unsolicited scripts or content or XSS vulnerabilities on your website. \nThe most important advantage of CSP for website maintainers is awareness. If you’ve set strict rules for image sources, and a script kiddie attempts to insert an image on your website from an unauthorized source, that image will be blocked, and you will be notified instantly. \nDevelopers, meanwhile, need to know exactly what their front-end code does, and CSP helps them master that. They will be prompted to refactor parts of their code (avoiding inline functions and styles, etc.) and to follow best practices. \nHow CSP Could Be Even Cooler Link \nIronically, CSP is too efficient in some browsers — it creates bugs with bookmarklets. So, do not update your CSP directives to allow bookmarklets. We can’t blame any one browser in particular; all of them have issues: \nFirefox19 \nChrome (Blink)20 \nWebKit21 \n Most of the time, the bugs are false positives in blocked notifications. All browser vendors are working on these issues, so we can expect fixes soon. Anyway, this should not stop you from using CSP. \nOther Resources And Articles Link \nGeneral Information Link \nContent Security Policy Quick Reference Guide22, Foundeo \n“Content Security Policy Level 223,” W3C \n“An Introduction to Content Security Policy24,” HTML5 Rocks \nSecurityHeaders.io25, Scott Helme \nCSP Useful, a Collection of Scripts, Thoughts About CSP26, Nicolas Hoffmann, GitHub \nCSP Validator27 \n“Upgrade Insecure Requests28,” W3C \n“CSP Cheat Sheet29,” Scott Helme \n Dropbox’s Series on Its CSP Policies Link \n“[CSP] On Reporting and Filtering30” \n“[CSP] Unsafe-Inline and Nonce Deployment31” \n“[CSP] The Unexpected Eval32” \n“[CSP] Third Party Integrations and Privilege Separation33” \n GitHub’s CSP policies Link \n“GitHub’s CSP journey34” \n Other Companies Link \n“We Said We’d Be Transparent: WIRED’s First Big HTTPS Snag35,” Wired \n“Content Security Policy for Single Page Web Apps36,” Square \n About Reporting Link \n“Twitter’s CSP Report Collector37,” Neil Matatall, GitHub \n Examples of Directives Link \nCollection of Examples38, Nicolas Hoffmann, GitHub \n The Future of CSP Link \n“Making CSP Great Again!39” (slides), Michele Spagnuolo and Lukas Weichselbaum \n“Content Security Policy Level 340,” W3C \n“Content Security Policy41,” W3C, GitHub \n (ds, il, al) \nFootnotes Link 1 https://rocssti.net/en/example-csp-paris-web2015 2 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 3 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 4 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 5 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 6 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 7 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 8 https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/ 9 http://caniuse.com/#feat=contentsecuritypolicy 10 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 11 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 12 http://caniuse.com/#feat=contentsecuritypolicy2 13 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 14 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 15 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 16 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 17 https://report-uri.io/ 18 https://github.com/nico3333fr/CSP-useful/tree/master/report-uri 19 https://bugzilla.mozilla.org/show_bug.cgi?id=866522 20 https://bugs.chromium.org/p/chromium/issues/detail?id=233903 21 https://bugs.webkit.org/show_bug.cgi?id=149000 22 http://content-security-policy.com/ 23 http://www.w3.org/TR/CSP/ 24 http://www.html5rocks.com/en/tutorials/security/content-security-policy/ 25 https://securityheaders.io/ 26 https://github.com/nico3333fr/CSP-useful 27 https://cspvalidator.org/ 28 https://www.w3.org/TR/upgrade-insecure-requests/ 29 https://scotthelme.co.uk/csp-cheat-sheet/ 30 https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ 31 https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/ 32 https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/ 33 https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/ 34 http://githubengineering.com/githubs-csp-journey/ 35 https://www.wired.com/2016/05/wired-first-big-https-rollout-snag/ 36 https://corner.squareup.com/2016/05/content-security-policy-single-page-app.html 37 https://oreoshake.github.io/csp/twitter/2014/07/25/twitters-csp-report-collector-design.html 38 https://github.com/nico3333fr/CSP-useful/tree/master/csp-for-third-party-services 39 https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum 40 https://www.w3.org/TR/CSP3/ 41 https://github.com/w3c/webappsec-csp/  \n  SmashingConf New York Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques. \n \n\n\t\n\tCSSJavaScriptSecurity \n\n\t↑ Back to top\n\n\tTweet itShare on Facebook \n\t\n\tAdvertisement","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"http://webdesign.jitheshpr.com/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T11:49:34Z","wm-id":377605,"wm-source":"http://webdesign.jitheshpr.com/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"http://americanfido.com/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T13:51:35Z","wm-id":377652,"wm-source":"http://americanfido.com/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"http://digitalmofo.com/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T18:49:42Z","wm-id":377751,"wm-source":"http://digitalmofo.com/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"Content Security Policy, Your Future Best Friend \n\t \n\t\t\n\t\tContent Security Policy, Your Future Best Friend\n \nBy Nicolas Hoffmann \nSeptember 12th, 2016 \nSecurityTools \n4 Comments  \n A long time ago, my personal website was attacked. I do not know how it happened, but it happened. Fortunately, the damage from the attack was quite minor: A piece of JavaScript was inserted at the bottom of some pages. I updated the FTP and other credentials, cleaned up some files, and that was that. \nOne point made me mad: At the time, there was no simple solution that could have informed me there was a problem and — more importantly — that could have protected the website’s visitors from this annoying piece of code. \nA solution exists now, and it is a technology that succeeds in both roles. Its name is content security policy (CSP). \nLink \nThe idea is quite simple: By sending a CSP header from a website, you are telling the browser what it is authorized to execute and what it is authorized to block. \nHere is an example with PHP: \n?php\n    header(\"Content-Security-Policy: your directives\");\n?\n \nLink \nYou may define global rules or define rules related to a type of asset: \ndefault-src 'self' ;\n     # self = same port, same domain name, same protocol = OK\n \nThe base argument is default-src: If no directive is defined for a type of asset, then the browser will use this value. \nscript-src 'self' www.google-analytics.com ;\n     # JS files on these domains = OK\n \nIn this example, we’ve authorized the domain name www.google-analytics.com as a source of JavaScript files to use on our website. We’ve added the keyword 'self'; if we redefined the directive script-src with another rule, it would override default-src rules. \nIf no scheme or port is specified, then it enforces the same scheme or port from the current page. This prevents mixed content. If the page is https://example.com, then you wouldn’t be able to load http://www.google-analytics.com/file.js because it would be blocked (the scheme wouldn’t match). However, there is an exception to allow a scheme upgrade. If http://example.com tries to load https://www.google-analytics.com/file.js, then the scheme or port would be allowed to change to facilitate the scheme upgrade. \nstyle-src 'self' data: ;\n     # Data-Uri in a CSS = OK\n \nIn this example, the keyword data: authorizes embedded content in CSS files. \nUnder the CSP level 1 specification, you may also define rules for the following: \nimg-src\n\nvalid sources of images \nconnect-src\n\napplies to XMLHttpRequest (AJAX), WebSocket or EventSource \nfont-src\n\nvalid sources of fonts \nobject-src\n\nvalid sources of plugins (for example, object, embed, applet) \nmedia-src\n\nvalid sources of audio and video \n CSP level 2 rules include the following: \nchild-src\n\nvalid sources of web workers and elements such as frame and iframe (this replaces the deprecated frame-src from CSP level 1) \nform-action\n\nvalid sources that can be used as an HTML form action \nframe-ancestors\n\nvalid sources for embedding the resource using frame, iframe, object, embed or applet. \nupgrade-insecure-requests\n\ninstructs user agents to rewrite URL schemes, changing HTTP to HTTPS (for websites with a lot of old URLs that need to be rewritten). \n For better backwards-compatibility with deprecated properties, you may simply copy the contents of the actual directive and duplicate them in the deprecated one. For example, you may copy the contents of child-src and duplicate them in frame-src. \nCSP 2 allows you to whitelist paths (CSP 1 allows only domains to be whitelisted). So, rather than whitelisting all of www.foo.com, you could whitelist www.foo.com/some/folder to restrict it further. This does require CSP 2 support in the browser, but it is obviously more secure. \nLink \nI made a simple example for the Paris Web 2015 conference, where I presented a talk entitled “CSP in Action1.” \nWithout CSP, the page would look like this: \nThis page without CSP, ugly and defaced2\nView large version3  Not very nice. What if we enabled the following CSP directives? \n?php\n    header(\"Content-Security-Policy: \n      default-src 'self' ;\n      script-src 'self' www.google-analytics.com stats.g.doubleclick.net ; \n      style-src 'self' data: ;\n      img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;\n      frame-src 'self' ;\");\n?\n \nWhat would the browser do? It would (very strictly) apply these directives under the primary rule of CSP, which is that anything not authorized in a CSP directive will be blocked (“blocked” meaning not executed, not displayed and not used by the website). \nBy default in CSP, inline scripts and styles are not authorized, which means that every script, onclick or style attribute will be blocked. You could authorize inline CSS with style-src 'unsafe-inline' ;. \nIn a modern browser with CSP support, the example would look like this: \nThis page with CSP, really better4\nView large version5  What happened? The browser applied the directives and rejected anything that was not authorized. It sent these notifications to the console: \nCSP notifications6\nView large version7  If you’re still not convinced of the value of CSP, have a look at Aaron Gustafson’s article “More Proof We Don’t Control Our Web Pages8.” \nOf course, you may use stricter directives than the ones in the example provided above: \nset default-src to 'none', \nspecify what you need for each rule, \nspecify the exact paths of required files, \netc. \n Link \nLink \nCSP is not a nightly feature requiring three flags to be activated in order for it to work. CSP levels 1 and 2 are candidate recommendations! Browser support for CSP level 19 is excellent. \nCSP Level 1 support on Can I Use10\nView large version11  The level 2 specification is more recent12, so it is a bit less supported. \nCSP Level 2 support on Can I Use13\nView large version14  CSP level 3 is an early draft now, so it is not yet supported, but you can already do great things with levels 1 and 2. \nLink \nCSP has been designed to reduce cross-site scripting (XSS) risks, which is why enabling inline scripts in script-src directives is not recommended. Firefox illustrates this issue very nicely: In the browser, hit Shift + F2 and type security csp, and it will show you directives and advice. For example, here it is used on Twitter’s website: \nCSP display on Firefox15\nView large version16  Another possibility for inline scripts or inline styles, if you really have to use them, is to create a hash value. For example, suppose you need to have this inline script: \nscriptalert('Hello, world.');/script\n\n \nYou might add 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=' as a valid source in your script-src directives. The hash generated is the result of this in PHP: \n?php\n    echo base64_encode(hash('sha256', \"alert('Hello, world.');\", true));\n?\n \nI said earlier that CSP is designed to reduce XSS risks — I could have added, “… and reduce the risks of unsolicited content.” With CSP, you have to know where your sources of content are and what they are doing on your front end (inline styles, etc.). CSP can also help you force contributors, developers and others to respect your rules about sources of content! \nNow your question is, “OK, this is great, but how do we use it in a production environment?” \nLink \nThe easiest way to get discouraged with using CSP the first time is to test it in a live environment, thinking, “This will be easy. My code is bad ass and perfectly clean.” Don’t do this. I did it. It’s stupid, trust me. \nAs I explained, CSP directives are activated with a CSP header — there is no middle ground. You are the weak link here. You might forget to authorize something or forget a piece of code on your website. CSP will not forgive your oversight. However, two features of CSP greatly simplify this problem. \nLink \nRemember the notifications that CSP sends to the console? The directive report-uri can be used to tell the browser to send them to the specified address. Reports are sent in JSON format. \nreport-uri /csp-parser.php ;\n \nSo, in the csp-parser.php file, we can process the data sent by the browser. Here is the most basic example in PHP: \n$data = file_get_contents('php://input');\n\n    if ($data = json_decode($data, true)) {\n     $data = json_encode(\n      $data,\n      JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES\n      );\n     mail(EMAIL, SUBJECT, $data);\n    }\n \nThis notification will be transformed into an email. During development, you might not need anything more complex than this. \nFor a production environment (or a more visited development environment), you’d better use a way other than email to collect information, because there is no auth or rate limiting on the endpoint, and CSP can be very noisy. Just imagine a page that generates 100 CSP notifications (for example, a script that display images from an unauthorized source) and that is viewed 100 times a day — you could get 10,000 notifications a day! \nA service such as report-uri.io17 can be used to simplify the management of reporting. You can see other simple examples for report-uri18 (with a database, with some optimizations, etc.) on GitHub. \nLink \nAs we have seen, the biggest issue is that there is no middle ground between CSP being enabled and disabled. However, a feature named report-only sends a slightly different header: \n?php\n    header(\"Content-Security-Policy-Report-Only: your directives\");\n?\n \nBasically, this tells the browser, “Act as if these CSP directives were being applied, but do not block anything. Just send me the notifications.” It is a great way to test directives without the risk of blocking any required assets. \nWith report-only and report-uri, you can test CSP directives with no risk, and you can monitor in real time everything CSP-related on a website. These two features are really powerful for deploying and maintaining CSP! \nLink \nLink \nCSP is most important for your users: They don’t have to suffer any unsolicited scripts or content or XSS vulnerabilities on your website. \nThe most important advantage of CSP for website maintainers is awareness. If you’ve set strict rules for image sources, and a script kiddie attempts to insert an image on your website from an unauthorized source, that image will be blocked, and you will be notified instantly. \nDevelopers, meanwhile, need to know exactly what their front-end code does, and CSP helps them master that. They will be prompted to refactor parts of their code (avoiding inline functions and styles, etc.) and to follow best practices. \nLink \nIronically, CSP is too efficient in some browsers — it creates bugs with bookmarklets. So, do not update your CSP directives to allow bookmarklets. We can’t blame any one browser in particular; all of them have issues: \nFirefox19 \nChrome (Blink)20 \nWebKit21 \n Most of the time, the bugs are false positives in blocked notifications. All browser vendors are working on these issues, so we can expect fixes soon. Anyway, this should not stop you from using CSP. \nLink \nLink \nContent Security Policy Quick Reference Guide22, Foundeo \n“Content Security Policy Level 223,” W3C \n“An Introduction to Content Security Policy24,” HTML5 Rocks \nSecurityHeaders.io25, Scott Helme \nCSP Useful, a Collection of Scripts, Thoughts About CSP26, Nicolas Hoffmann, GitHub \nCSP Validator27 \n“Upgrade Insecure Requests28,” W3C \n“CSP Cheat Sheet29,” Scott Helme \n Link \n“[CSP] On Reporting and Filtering30” \n“[CSP] Unsafe-Inline and Nonce Deployment31” \n“[CSP] The Unexpected Eval32” \n“[CSP] Third Party Integrations and Privilege Separation33” \n Link \n“GitHub’s CSP journey34” \n Link \n“We Said We’d Be Transparent: WIRED’s First Big HTTPS Snag35,” Wired \n“Content Security Policy for Single Page Web Apps36,” Square \n Link \n“Twitter’s CSP Report Collector37,” Neil Matatall, GitHub \n Link \nCollection of Examples38, Nicolas Hoffmann, GitHub \n Link \n“Making CSP Great Again!39” (slides), Michele Spagnuolo and Lukas Weichselbaum \n“Content Security Policy Level 340,” W3C \n“Content Security Policy41,” W3C, GitHub \n (ds, il, al) \nFootnotes Link \n1 https://rocssti.net/en/example-csp-paris-web2015 \n2 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg \n3 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg \n4 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg \n5 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg \n6 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg \n7 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg \n8 https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/ \n9 http://caniuse.com/#feat=contentsecuritypolicy \n10 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg \n11 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg \n12 http://caniuse.com/#feat=contentsecuritypolicy2 \n13 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg \n14 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg \n15 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg \n16 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg \n17 https://report-uri.io/ \n18 https://github.com/nico3333fr/CSP-useful/tree/master/report-uri \n19 https://bugzilla.mozilla.org/show_bug.cgi?id=866522 \n20 https://bugs.chromium.org/p/chromium/issues/detail?id=233903 \n21 https://bugs.webkit.org/show_bug.cgi?id=149000 \n22 http://content-security-policy.com/ \n23 http://www.w3.org/TR/CSP/ \n24 http://www.html5rocks.com/en/tutorials/security/content-security-policy/ \n25 https://securityheaders.io/ \n26 https://github.com/nico3333fr/CSP-useful \n27 https://cspvalidator.org/ \n28 https://www.w3.org/TR/upgrade-insecure-requests/ \n29 https://scotthelme.co.uk/csp-cheat-sheet/ \n30 https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ \n31 https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/ \n32 https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/ \n33 https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/ \n34 http://githubengineering.com/githubs-csp-journey/ \n35 https://www.wired.com/2016/05/wired-first-big-https-rollout-snag/ \n36 https://corner.squareup.com/2016/05/content-security-policy-single-page-app.html \n37 https://oreoshake.github.io/csp/twitter/2014/07/25/twitters-csp-report-collector-design.html \n38 https://github.com/nico3333fr/CSP-useful/tree/master/csp-for-third-party-services \n39 https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum \n40 https://www.w3.org/TR/CSP3/ \n41 https://github.com/w3c/webappsec-csp/ \n SmashingConf New York Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques. \n\n\t↑ Back to top \n\tTweet itShare on Facebook \n Article source: https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/ \t\t\t \n\tSeptember 12, 2016 \n\t\t\t\t\t\t\t\n\t\t\t\tComment\t\t\t \n\t\t\t\t\n\t\t\tCategories: Web Developent\t\t \n\t\t\n\t\t\t\t\t\tTags: css, html, java, web | \n\t\t\t\t\t \n\t\t\t\t\t\tPermlink","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"http://www.webhostingreviewsbynerds.com/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T21:26:47Z","wm-id":377793,"wm-source":"http://www.webhostingreviewsbynerds.com/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"Content Security Policy, Your Future Best Friend\n By Nicolas Hoffmann September 12th, 2016 SecurityTools 4 Comments  A long time ago, my personal website was attacked. I do not know how it happened, but it happened. Fortunately, the damage from the attack was quite minor: A piece of JavaScript was inserted at the bottom of some pages. I updated the FTP and other credentials, cleaned up some files, and that was that. One point made me mad: At the time, there was no simple solution that could have informed me there was a problem and — more importantly — that could have protected the website’s visitors from this annoying piece of code. A solution exists now, and it is a technology that succeeds in both roles. Its name is content security policy (CSP). Link The idea is quite simple: By sending a CSP header from a website, you are telling the browser what it is authorized to execute and what it is authorized to block. Here is an example with PHP: ?php\n    header(\"Content-Security-Policy: your directives\");\n?\n Link You may define global rules or define rules related to a type of asset: default-src 'self' ;\n     # self = same port, same domain name, same protocol = OK\n The base argument is default-src: If no directive is defined for a type of asset, then the browser will use this value. script-src 'self' www.google-analytics.com ;\n     # JS files on these domains = OK\n In this example, we’ve authorized the domain name www.google-analytics.com as a source of JavaScript files to use on our website. We’ve added the keyword 'self'; if we redefined the directive script-src with another rule, it would override default-src rules. If no scheme or port is specified, then it enforces the same scheme or port from the current page. This prevents mixed content. If the page is https://example.com, then you wouldn’t be able to load http://www.google-analytics.com/file.js because it would be blocked (the scheme wouldn’t match). However, there is an exception to allow a scheme upgrade. If http://example.com tries to load https://www.google-analytics.com/file.js, then the scheme or port would be allowed to change to facilitate the scheme upgrade. style-src 'self' data: ;\n     # Data-Uri in a CSS = OK\n In this example, the keyword data: authorizes embedded content in CSS files. Under the CSP level 1 specification, you may also define rules for the following: img-src\n valid sources of images connect-src\n applies to XMLHttpRequest (AJAX), WebSocket or EventSource font-src\n valid sources of fonts object-src\n valid sources of plugins (for example, object, embed, applet) media-src\n valid sources of audio and video  CSP level 2 rules include the following: child-src\n valid sources of web workers and elements such as frame and iframe (this replaces the deprecated frame-src from CSP level 1) form-action\n valid sources that can be used as an HTML form action frame-ancestors\n valid sources for embedding the resource using frame, iframe, object, embed or applet. upgrade-insecure-requests\n instructs user agents to rewrite URL schemes, changing HTTP to HTTPS (for websites with a lot of old URLs that need to be rewritten).  For better backwards-compatibility with deprecated properties, you may simply copy the contents of the actual directive and duplicate them in the deprecated one. For example, you may copy the contents of child-src and duplicate them in frame-src. CSP 2 allows you to whitelist paths (CSP 1 allows only domains to be whitelisted). So, rather than whitelisting all of www.foo.com, you could whitelist www.foo.com/some/folder to restrict it further. This does require CSP 2 support in the browser, but it is obviously more secure. Link I made a simple example for the Paris Web 2015 conference, where I presented a talk entitled “CSP in Action1.” Without CSP, the page would look like this:  This page without CSP, ugly and defaced2\nView large version3  Not very nice. What if we enabled the following CSP directives? ?php\n    header(\"Content-Security-Policy: \n      default-src 'self' ;\n      script-src 'self' www.google-analytics.com stats.g.doubleclick.net ; \n      style-src 'self' data: ;\n      img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;\n      frame-src 'self' ;\");\n?\n What would the browser do? It would (very strictly) apply these directives under the primary rule of CSP, which is that anything not authorized in a CSP directive will be blocked (“blocked” meaning not executed, not displayed and not used by the website). By default in CSP, inline scripts and styles are not authorized, which means that every script, onclick or style attribute will be blocked. You could authorize inline CSS with style-src 'unsafe-inline' ;. In a modern browser with CSP support, the example would look like this:  This page with CSP, really better4\nView large version5  What happened? The browser applied the directives and rejected anything that was not authorized. It sent these notifications to the console:  CSP notifications6\nView large version7  If you’re still not convinced of the value of CSP, have a look at Aaron Gustafson’s article “More Proof We Don’t Control Our Web Pages8.” Of course, you may use stricter directives than the ones in the example provided above: set default-src to 'none', specify what you need for each rule, specify the exact paths of required files, etc.  Link Link CSP is not a nightly feature requiring three flags to be activated in order for it to work. CSP levels 1 and 2 are candidate recommendations! Browser support for CSP level 19 is excellent.  CSP Level 1 support on Can I Use10\nView large version11  The level 2 specification is more recent12, so it is a bit less supported.  CSP Level 2 support on Can I Use13\nView large version14  CSP level 3 is an early draft now, so it is not yet supported, but you can already do great things with levels 1 and 2. Link CSP has been designed to reduce cross-site scripting (XSS) risks, which is why enabling inline scripts in script-src directives is not recommended. Firefox illustrates this issue very nicely: In the browser, hit Shift + F2 and type security csp, and it will show you directives and advice. For example, here it is used on Twitter’s website:  CSP display on Firefox15\nView large version16  Another possibility for inline scripts or inline styles, if you really have to use them, is to create a hash value. For example, suppose you need to have this inline script: scriptalert('Hello, world.');/script\n\n You might add 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=' as a valid source in your script-src directives. The hash generated is the result of this in PHP: ?php\n    echo base64_encode(hash('sha256', \"alert('Hello, world.');\", true));\n?\n I said earlier that CSP is designed to reduce XSS risks — I could have added, “… and reduce the risks of unsolicited content.” With CSP, you have to know where your sources of content are and what they are doing on your front end (inline styles, etc.). CSP can also help you force contributors, developers and others to respect your rules about sources of content! Now your question is, “OK, this is great, but how do we use it in a production environment?” Link The easiest way to get discouraged with using CSP the first time is to test it in a live environment, thinking, “This will be easy. My code is bad ass and perfectly clean.” Don’t do this. I did it. It’s stupid, trust me. As I explained, CSP directives are activated with a CSP header — there is no middle ground. You are the weak link here. You might forget to authorize something or forget a piece of code on your website. CSP will not forgive your oversight. However, two features of CSP greatly simplify this problem. Link Remember the notifications that CSP sends to the console? The directive report-uri can be used to tell the browser to send them to the specified address. Reports are sent in JSON format. report-uri /csp-parser.php ;\n So, in the csp-parser.php file, we can process the data sent by the browser. Here is the most basic example in PHP: $data = file_get_contents('php://input');\n\n    if ($data = json_decode($data, true)) {\n     $data = json_encode(\n      $data,\n      JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES\n      );\n     mail(EMAIL, SUBJECT, $data);\n    }\n This notification will be transformed into an email. During development, you might not need anything more complex than this. For a production environment (or a more visited development environment), you’d better use a way other than email to collect information, because there is no auth or rate limiting on the endpoint, and CSP can be very noisy. Just imagine a page that generates 100 CSP notifications (for example, a script that display images from an unauthorized source) and that is viewed 100 times a day — you could get 10,000 notifications a day! A service such as report-uri.io17 can be used to simplify the management of reporting. You can see other simple examples for report-uri18 (with a database, with some optimizations, etc.) on GitHub. Link As we have seen, the biggest issue is that there is no middle ground between CSP being enabled and disabled. However, a feature named report-only sends a slightly different header: ?php\n    header(\"Content-Security-Policy-Report-Only: your directives\");\n?\n Basically, this tells the browser, “Act as if these CSP directives were being applied, but do not block anything. Just send me the notifications.” It is a great way to test directives without the risk of blocking any required assets. With report-only and report-uri, you can test CSP directives with no risk, and you can monitor in real time everything CSP-related on a website. These two features are really powerful for deploying and maintaining CSP! Link Link CSP is most important for your users: They don’t have to suffer any unsolicited scripts or content or XSS vulnerabilities on your website. The most important advantage of CSP for website maintainers is awareness. If you’ve set strict rules for image sources, and a script kiddie attempts to insert an image on your website from an unauthorized source, that image will be blocked, and you will be notified instantly. Developers, meanwhile, need to know exactly what their front-end code does, and CSP helps them master that. They will be prompted to refactor parts of their code (avoiding inline functions and styles, etc.) and to follow best practices. Link Ironically, CSP is too efficient in some browsers — it creates bugs with bookmarklets. So, do not update your CSP directives to allow bookmarklets. We can’t blame any one browser in particular; all of them have issues: Firefox19 Chrome (Blink)20 WebKit21  Most of the time, the bugs are false positives in blocked notifications. All browser vendors are working on these issues, so we can expect fixes soon. Anyway, this should not stop you from using CSP. Link Link Content Security Policy Quick Reference Guide22, Foundeo “Content Security Policy Level 223,” W3C “An Introduction to Content Security Policy24,” HTML5 Rocks SecurityHeaders.io25, Scott Helme CSP Useful, a Collection of Scripts, Thoughts About CSP26, Nicolas Hoffmann, GitHub CSP Validator27 “Upgrade Insecure Requests28,” W3C “CSP Cheat Sheet29,” Scott Helme  Link “[CSP] On Reporting and Filtering30” “[CSP] Unsafe-Inline and Nonce Deployment31” “[CSP] The Unexpected Eval32” “[CSP] Third Party Integrations and Privilege Separation33”  Link “GitHub’s CSP journey34”  Link “We Said We’d Be Transparent: WIRED’s First Big HTTPS Snag35,” Wired “Content Security Policy for Single Page Web Apps36,” Square  Link “Twitter’s CSP Report Collector37,” Neil Matatall, GitHub  Link Collection of Examples38, Nicolas Hoffmann, GitHub  Link “Making CSP Great Again!39” (slides), Michele Spagnuolo and Lukas Weichselbaum “Content Security Policy Level 340,” W3C “Content Security Policy41,” W3C, GitHub  (ds, il, al) Footnotes Link 1 https://rocssti.net/en/example-csp-paris-web2015 2 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 3 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 4 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 5 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 6 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 7 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 8 https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/ 9 http://caniuse.com/#feat=contentsecuritypolicy 10 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 11 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 12 http://caniuse.com/#feat=contentsecuritypolicy2 13 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 14 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 15 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 16 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 17 https://report-uri.io/ 18 https://github.com/nico3333fr/CSP-useful/tree/master/report-uri 19 https://bugzilla.mozilla.org/show_bug.cgi?id=866522 20 https://bugs.chromium.org/p/chromium/issues/detail?id=233903 21 https://bugs.webkit.org/show_bug.cgi?id=149000 22 http://content-security-policy.com/ 23 http://www.w3.org/TR/CSP/ 24 http://www.html5rocks.com/en/tutorials/security/content-security-policy/ 25 https://securityheaders.io/ 26 https://github.com/nico3333fr/CSP-useful 27 https://cspvalidator.org/ 28 https://www.w3.org/TR/upgrade-insecure-requests/ 29 https://scotthelme.co.uk/csp-cheat-sheet/ 30 https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ 31 https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/ 32 https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/ 33 https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/ 34 http://githubengineering.com/githubs-csp-journey/ 35 https://www.wired.com/2016/05/wired-first-big-https-rollout-snag/ 36 https://corner.squareup.com/2016/05/content-security-policy-single-page-app.html 37 https://oreoshake.github.io/csp/twitter/2014/07/25/twitters-csp-report-collector-design.html 38 https://github.com/nico3333fr/CSP-useful/tree/master/csp-for-third-party-services 39 https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum 40 https://www.w3.org/TR/CSP3/ 41 https://github.com/w3c/webappsec-csp/  SmashingConf New York Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.  ↑ Back to top  Tweet itShare on Facebook","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"John Anderson","photo":"","url":"http://www.wordpressstyles.com/author/john-anderson/"},"url":"http://www.wordpressstyles.com/2016/09/12/content-security-policy-your-future-best-friend/","published":null,"wm-received":"2016-09-12T22:00:45Z","wm-id":377804,"wm-source":"http://www.wordpressstyles.com/2016/09/12/content-security-policy-your-future-best-friend/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","name":"by John Anderson   September 12, 2016 in web design services, Web Design Software, Web Design Templates, Web Design Trends, Web Development, Web Development Company  No Comments  0   \n A long time ago, my personal website was attacked. I do not know how it happened, but it happened. Fortunately, the damage from the attack was quite minor: A piece of JavaScript was inserted at the bottom of some pages. I updated the FTP and other credentials, cleaned up some files, and that was that. One point made me mad: At the time, there was no simple solution that could have informed me there was a problem and — more importantly — that could have protected the website’s visitors from this annoying piece of code. A solution exists now, and it is a technology that succeeds in both roles. Its name is content security policy (CSP).  What Is A CSP? Link The idea is quite simple: By sending a CSP header from a website, you are telling the browser what it is authorized to execute and what it is authorized to block. Here is an example with PHP: <?php\n    header(\"Content-Security-Policy: <your directives>\");\n?>\n  Some Directives Link You may define global rules or define rules related to a type of asset: default-src 'self' ;\n     # self = same port, same domain name, same protocol => OK\n The base argument is default-src: If no directive is defined for a type of asset, then the browser will use this value. script-src 'self' www.google-analytics.com ;\n     # JS files on these domains => OK\n In this example, we’ve authorized the domain name www.google-analytics.com as a source of JavaScript files to use on our website. We’ve added the keyword 'self'; if we redefined the directive script-src with another rule, it would override default-src rules. If no scheme or port is specified, then it enforces the same scheme or port from the current page. This prevents mixed content. If the page is https://example.com, then you wouldn’t be able to load http://www.google-analytics.com/file.js because it would be blocked (the scheme wouldn’t match). However, there is an exception to allow a scheme upgrade. If http://example.com tries to load https://www.google-analytics.com/file.js, then the scheme or port would be allowed to change to facilitate the scheme upgrade. style-src 'self' data: ;\n     # Data-Uri in a CSS => OK\n In this example, the keyword data: authorizes embedded content in CSS files. Under the CSP level 1 specification, you may also define rules for the following:  img-src\nvalid sources of images  connect-src\napplies to XMLHttpRequest (AJAX), WebSocket or EventSource  font-src\nvalid sources of fonts  object-src\nvalid sources of plugins (for example, <object>, <embed>, <applet>)  media-src\nvalid sources of <audio> and <video>  CSP level 2 rules include the following:  child-src\nvalid sources of web workers and elements such as <frame> and <iframe> (this replaces the deprecated frame-src from CSP level 1)  form-action\nvalid sources that can be used as an HTML <form> action  frame-ancestors\nvalid sources for embedding the resource using <frame>, <iframe>, <object>, <embed> or <applet>.  upgrade-insecure-requests\ninstructs user agents to rewrite URL schemes, changing HTTP to HTTPS (for websites with a lot of old URLs that need to be rewritten).  For better backwards-compatibility with deprecated properties, you may simply copy the contents of the actual directive and duplicate them in the deprecated one. For example, you may copy the contents of child-src and duplicate them in frame-src. CSP 2 allows you to whitelist paths (CSP 1 allows only domains to be whitelisted). So, rather than whitelisting all of www.foo.com, you could whitelist www.foo.com/some/folder to restrict it further. This does require CSP 2 support in the browser, but it is obviously more secure.  An Example Link I made a simple example for the Paris Web 2015 conference, where I presented a talk entitled “CSP in Action1.” Without CSP, the page would look like this:  This page without CSP, ugly and defaced  Content Security Policy, Your Future Best Friend Content Security Policy Your Future Best Friend2\nView large version3  Not very nice. What if we enabled the following CSP directives? <?php\n    header(\"Content-Security-Policy: \n      default-src 'self' ;\n      script-src 'self' www.google-analytics.com stats.g.doubleclick.net ; \n      style-src 'self' data: ;\n      img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ;\n      frame-src 'self' ;\");\n?>\n What would the browser do? It would (very strictly) apply these directives under the primary rule of CSP, which is that anything not authorized in a CSP directive will be blocked (“blocked” meaning not executed, not displayed and not used by the website). By default in CSP, inline scripts and styles are not authorized, which means that every <script>, onclick or style attribute will be blocked. You could authorize inline CSS with style-src 'unsafe-inline' ;. In a modern browser with CSP support, the example would look like this:  This page with CSP, really better  Content Security Policy, Your Future Best Friend 1473717583 71 Content Security Policy Your Future Best Friend4\nView large version5  What happened? The browser applied the directives and rejected anything that was not authorized. It sent these notifications to the console:  CSP notifications  Content Security Policy, Your Future Best Friend 1473717583 892 Content Security Policy Your Future Best Friend6\nView large version7  If you’re still not convinced of the value of CSP, have a look at Aaron Gustafson’s article “More Proof We Don’t Control Our Web Pages8.” Of course, you may use stricter directives than the ones in the example provided above: set default-src to 'none', specify what you need for each rule, specify the exact paths of required files, etc.   More Information On CSP Link  Support Link CSP is not a nightly feature requiring three flags to be activated in order for it to work. CSP levels 1 and 2 are candidate recommendations! Browser support for CSP level 19 is excellent.  CSP Level 1 support on Can I Use  Content Security Policy, Your Future Best Friend 1473717583 348 Content Security Policy Your Future Best Friend10\nView large version11  The level 2 specification is more recent12, so it is a bit less supported.  CSP Level 2 support on Can I Use  Content Security Policy, Your Future Best Friend 1473717584 888 Content Security Policy Your Future Best Friend13\nView large version14  CSP level 3 is an early draft now, so it is not yet supported, but you can already do great things with levels 1 and 2.  Other Considerations Link CSP has been designed to reduce cross-site scripting (XSS) risks, which is why enabling inline scripts in script-src directives is not recommended. Firefox illustrates this issue very nicely: In the browser, hit Shift + F2 and type security csp, and it will show you directives and advice. For example, here it is used on Twitter’s website:  CSP display on Firefox  Content Security Policy, Your Future Best Friend 1473717584 402 Content Security Policy Your Future Best Friend15\nView large version16  Another possibility for inline scripts or inline styles, if you really have to use them, is to create a hash value. For example, suppose you need to have this inline script: <script>alert('Hello, world.');</script>\n\n You might add 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng=' as a valid source in your script-src directives. The hash generated is the result of this in PHP: <?php\n    echo base64_encode(hash('sha256', \"alert('Hello, world.');\", true));\n?>\n I said earlier that CSP is designed to reduce XSS risks — I could have added, “… and reduce the risks of unsolicited content.” With CSP, you have to know where your sources of content are and what they are doing on your front end (inline styles, etc.). CSP can also help you force contributors, developers and others to respect your rules about sources of content! Now your question is, “OK, this is great, but how do we use it in a production environment?”  How To Use It In The Real World Link The easiest way to get discouraged with using CSP the first time is to test it in a live environment, thinking, “This will be easy. My code is bad ass and perfectly clean.” Don’t do this. I did it. It’s stupid, trust me. As I explained, CSP directives are activated with a CSP header — there is no middle ground. You are the weak link here. You might forget to authorize something or forget a piece of code on your website. CSP will not forgive your oversight. However, two features of CSP greatly simplify this problem.  report-uri Link Remember the notifications that CSP sends to the console? The directive report-uri can be used to tell the browser to send them to the specified address. Reports are sent in JSON format. report-uri /csp-parser.php ;\n So, in the csp-parser.php file, we can process the data sent by the browser. Here is the most basic example in PHP: $data = file_get_contents('php://input');\n\n    if ($data = json_decode($data, true)) {\n     $data = json_encode(\n      $data,\n      JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES\n      );\n     mail(EMAIL, SUBJECT, $data);\n    }\n This notification will be transformed into an email. During development, you might not need anything more complex than this. For a production environment (or a more visited development environment), you’d better use a way other than email to collect information, because there is no auth or rate limiting on the endpoint, and CSP can be very noisy. Just imagine a page that generates 100 CSP notifications (for example, a script that display images from an unauthorized source) and that is viewed 100 times a day — you could get 10,000 notifications a day! A service such as report-uri.io17 can be used to simplify the management of reporting. You can see other simple examples for report-uri18 (with a database, with some optimizations, etc.) on GitHub.  report-only Link As we have seen, the biggest issue is that there is no middle ground between CSP being enabled and disabled. However, a feature named report-only sends a slightly different header: <?php\n    header(\"Content-Security-Policy-Report-Only: <your directives>\");\n?>\n Basically, this tells the browser, “Act as if these CSP directives were being applied, but do not block anything. Just send me the notifications.” It is a great way to test directives without the risk of blocking any required assets. With report-only and report-uri, you can test CSP directives with no risk, and you can monitor in real time everything CSP-related on a website. These two features are really powerful for deploying and maintaining CSP!  Conclusion Link  Why CSP Is Cool Link CSP is most important for your users: They don’t have to suffer any unsolicited scripts or content or XSS vulnerabilities on your website. The most important advantage of CSP for website maintainers is awareness. If you’ve set strict rules for image sources, and a script kiddie attempts to insert an image on your website from an unauthorized source, that image will be blocked, and you will be notified instantly. Developers, meanwhile, need to know exactly what their front-end code does, and CSP helps them master that. They will be prompted to refactor parts of their code (avoiding inline functions and styles, etc.) and to follow best practices.  How CSP Could Be Even Cooler Link Ironically, CSP is too efficient in some browsers — it creates bugs with bookmarklets. So, do not update your CSP directives to allow bookmarklets. We can’t blame any one browser in particular; all of them have issues: Most of the time, the bugs are false positives in blocked notifications. All browser vendors are working on these issues, so we can expect fixes soon. Anyway, this should not stop you from using CSP.  Other Resources And Articles Link  General Information Link  Content Security Policy Quick Reference Guide22, Foundeo “Content Security Policy Level 223,” W3C “An Introduction to Content Security Policy24,” HTML5 Rocks  SecurityHeaders.io25, Scott Helme  CSP Useful, a Collection of Scripts, Thoughts About CSP26, Nicolas Hoffmann, GitHub  CSP Validator27 “Upgrade Insecure Requests28,” W3C “CSP Cheat Sheet29,” Scott Helme   Dropbox’s Series on Its CSP Policies Link  GitHub’s CSP policies Link  Other Companies Link  About Reporting Link  Examples of Directives Link  The Future of CSP Link (ds, il, al) 1 https://rocssti.net/en/example-csp-paris-web2015 2 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 3 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing1b.jpg 4 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 5 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing5.jpg 6 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 7 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing2.jpg 8 https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/ 9 http://caniuse.com/#feat=contentsecuritypolicy 10 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 11 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing3.jpg 12 http://caniuse.com/#feat=contentsecuritypolicy2 13 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 14 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing4.jpg 15 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 16 https://www.smashingmagazine.com/wp-content/uploads/2016/09/csp_smashing6b.jpg 17 https://report-uri.io/ 18 https://github.com/nico3333fr/CSP-useful/tree/master/report-uri 19 https://bugzilla.mozilla.org/show_bug.cgi?id=866522 20 https://bugs.chromium.org/p/chromium/issues/detail?id=233903 21 https://bugs.webkit.org/show_bug.cgi?id=149000 22 http://content-security-policy.com/ 23 http://www.w3.org/TR/CSP/ 24 http://www.html5rocks.com/en/tutorials/security/content-security-policy/ 25 https://securityheaders.io/ 26 https://github.com/nico3333fr/CSP-useful 27 https://cspvalidator.org/ 28 https://www.w3.org/TR/upgrade-insecure-requests/ 29 https://scotthelme.co.uk/csp-cheat-sheet/ 30 https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ 31 https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/ 32 https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/ 33 https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/ 34 http://githubengineering.com/githubs-csp-journey/ 35 https://www.wired.com/2016/05/wired-first-big-https-rollout-snag/ 36 https://corner.squareup.com/2016/05/content-security-policy-single-page-app.html 37 https://oreoshake.github.io/csp/twitter/2014/07/25/twitters-csp-report-collector-design.html 38 https://github.com/nico3333fr/CSP-useful/tree/master/csp-for-third-party-services 39 https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum 40 https://www.w3.org/TR/CSP3/ 41 https://github.com/w3c/webappsec-csp/   ↑ Back to top  Tweet itShare on Facebook  Advertisement  \n\nSource link   Share       \n  John Anderson   Recommended Posts   Web Dеѕіgn Trеndѕ: To Follow аnd Nоt Tо Fоllоw? August 29, 2016     Wеb Dеѕіgn Trеndѕ That Arе Going tо Dоmіnаtе іn 2016 August 29, 2016     Top Web Design Trеndѕ tо Lооk Out Fоr in 2016 August 29, 2016        Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * Comment Name *  Email *  Website           Recent Posts   Content Security Policy, Your Future Best Friend  Design Free Websites  CUSTOM WEBSITE DESIGN PACKAGE + FREE HOSTING AND DOMAIN NAME  Cheap Website Design  Custom Design Business Or Personal Website With Free Hosting!!! Websites   Recent Comments    Archives  September 2016 August 2016   Categories  seo company seo marketing seo optimization seo services Web Design web design company web design services Web Design Software Web Design Templates Web Design Trends Web Development Web Development Company Website Design WordPress Tutorials WordPress website        We'll send you news and offers twice a month.    Join       ABOUT US Wе lоvе tаkіng on challenging рrоjесtѕ thаt rеԛuіrе full-on соntеnt ѕtrаtеgу, thоughtful dеѕіgn, dеmаndіng dеvеlорmеnt, аnd ongoing mаrkеtіng.     RECENT POSTS  Content Security Policy, Your Future Best Friend September 12, 2016  Design Free Websites September 12, 2016  CUSTOM WEBSITE DESIGN PACKAGE + FREE HOSTING AND DOMAIN NAME September 12, 2016           www.wordpressstyles.com   About us Services Pricing Blog Contact Us ENES     Maxtheme.net","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false},{"type":"entry","author":{"type":"card","name":"","photo":"","url":""},"url":"https://kryptonsolid.com/politica-de-seguridad-de-contenido-su-futuro-mejor-amigo/","published":null,"wm-received":"2021-05-04T16:52:45Z","wm-id":1144377,"wm-source":"https://kryptonsolid.com/politica-de-seguridad-de-contenido-su-futuro-mejor-amigo/","wm-target":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","mention-of":"https://www.aaron-gustafson.com/notebook/more-proof-we-dont-control-our-web-pages/","wm-property":"mention-of","wm-private":false,"rels":{"canonical":"https://kryptonsolid.com/politica-de-seguridad-de-contenido-su-futuro-mejor-amigo/"}}]

Webmentions

  1. Adactio Links
    More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson ift.tt/1VYtn1F
    | Permalink

Shares