XMLHttpRequest will be more secure in the future

Some of the most recent iterations of the XHR specification at w3c (edited by Anne van Kesteren) includes excellent security choices which will lock down the JavaScript HTTPOnly edge-case exposure vectors.

The latest editorial draft of the XHR w3c spec http://dev.w3.org/2006/webapi/XMLHttpRequest/

• prevents creating set-cookie/2 headers via setRequestHeader() in a case insensitive way. (but XHR is free to send Cookie/2 headers for any existing cookie (HTTPOnly or otherwise).
• prevents reading set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way.

Excerpts from the spec:

getAllResponseHeaders(), method….
Return all the HTTP headers, excluding headers that case-insensitively match Set-Cookie or Set-Cookie2, as a single string, with each header line separated by a U+000D CR U+000A LF pair excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

setRequestHeader(header, value), method
For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers:
• Accept-Charset
• Accept-Encoding
• Authorization
• Connection
• Content-Length
• Cookie
• Cookie2
• Content-Transfer-Encoding
• Date
• Expect
• Host
• Keep-Alive
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via

I’m excited to see this key specification move in such a secure direction!