From nsXMLHttpRequest::GetResponseHeader: // See bug #380418. Hide "Set-Cookie" headers from non-chrome scripts. if (!nsContentUtils::IsCallerChrome() && (header.LowerCaseEqualsASCII("set-cookie") || header.LowerCaseEqualsASCII("set-cookie2"))) { NS_WARNING("blocked access to response header"); return; } This logic, and similar, needs to happen in the parent process. jduell suggested that we should put these checks in the parent side of the Necko e10s implementation. Ideally, we should ensure that cookie values and HTTP auth credentials are never sent into the child process. (The implementation of document.cookie should grab the cookie from the parent process at the time document.cookie is accessed by the content, and the parent process should block that from happening for httpOnly cookies.)

We can't do this unfortunately. The security checks that apply to CORS requests aren't done for things like <script> or <img> requests. While we could flag channels coming from XHR and do security checks only on those, that doesn't really help security-wise since the attacker can simply claim to not be doing an XHR request.

I think this bug is WONTFIX or INVALID

> Ideally, we should ensure that cookie values and HTTP auth credentials are never sent into the child process. Let's track those two fixes in bug 827853, and close this bug. Unless we can think of some way that XHR security for child requests will be different on the parent than the sec checks for regular HTTP requests (since the parent has to trust the child as to whether a given HTTP request is for XHR or not, I suspect the answer is no).