What's missing from this picture is that the browser can read, and send, cookies even if JavaScript can't.
That's why HttpOnly cookies exists: they are only available within the HTTP request.
So, a cross-origin HTTP request made using an XMLHttpRequest (or the fetch API) can include cookies that the JavaScript itself can't read. This is referred to as "credentials".
With XMLHttpRequest:
// from https://a.comconstxhr=newXMLHttpRequest();xhr.open('GET','https://b.com/c.json',true);xhr.withCredentials=true;xhr.send();
What's missing from this picture is that the browser can read, and send, cookies even if JavaScript can't.
That's why
HttpOnly
cookies exists: they are only available within the HTTP request.So, a cross-origin HTTP request made using an
XMLHttpRequest
(or thefetch
API) can include cookies that the JavaScript itself can't read. This is referred to as "credentials".With
XMLHttpRequest
:and
fetch
:Hopefully that makes sense!
By the way, this system (cross-origin, secure, HTTP-only cookies) is how TweetDeck and Twitter Lite's authentication works against the Twitter API.
Makes perfect sense. But it's not possible to configure that request by for example adding a authorization header with the value of a cookie.
Good point!