May I also suggest protecting Access-Control-Origin (since it's essentially a variant of the referer?). This is for setRequestHeader of course. So essentially summarizing my two requests for your convenience. 1. Mentioning for each header the reasons for restriction. (I think security is paramount but for shipped implementations I would hesitate to reduce surface area of attack unless there is a compelling reason. It's much harder to restrict once we ship!) 2. Protecting Access-Control-Origin header from being set in XHR. Cheers and thank you! From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Sunava Dutta Sent: Tuesday, April 15, 2008 2:59 PM To: Anne van Kesteren Cc: public-webapi@w3.org; Gideon Cohn; Ahmed Kamel; Zhenbin Xu; Doug Stamper Subject: XHR LC Draft Feedback Good to see the draft move to LC. * Removed dependency on DOM Level 3 Events * Removed dependency on Window Object 1.0 * Clearly marked which HTTP methods are to raise SECURITY_ERR Thanks for the changes. I noticed the draft (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) has called out the restricted headers. This is great. Perhaps it would be helpful to mention for each header, why they are restricted. It will help developers (and others concerned who are not security savvy) understand the security philosophy and also help to ensure that headers of equivalent function with different names are also submitted for consideration in this blocked list. (I don't have any that comes to mind currently). -- Sunava Dutta Program Manager (AJAX) - Developer Experience Team, Internet Explorer One Microsoft Way, Redmond WA 98052 TEL# (425) 705-1418 FAX# (425) 936-7329
Received on Friday, 18 April 2008 01:01:19 UTC