Cookies are not accessible within JavaScript (and the dev tools) but sent along with XHR request (no httponly used)

Question

I'm using both a front-end and a back-end application on a different domain with a session-based authorization. I have setup a working CORS configuration, which works as expected on localhost (e.g. from port :9000 to port :8080). As soon as I deploy the applications on secure domains (both domains only allow HTTPS), the CSRF cookie is not accessible anymore within JavaScript, leading to an incorrect follow-up request of the front-end (missing the CSRF header).

The cookie is set by the back-end in the Set-Cookie header without using the HttpOnly flag. It is actually set somewhere in the browser, because the follow-up request contains both the session cookie and the CSRF cookie. Trying to access it by JavaScript (using e.g. document.cookie in the console) returns an empty string. The DevTools of Chrome do not show any cookies on the front-end domain (the back-end domain is not even listed).

I'm expecting the cookie to be set and being visible on the current domain (front-end domain). I'm using the withCredentials flag of the axios library.

Do you have any idea, why the cookie cannot be accessed from JavaScript nor from the DevTools in Chrome? Does this have anything to do with the Strict-Transport-Security header?

---

Headers

1. Initial GET Response Header

HTTP/1.1 401 Unauthorized
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://[my-frontend-domain]
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Encoding: gzip
Content-Type: application/json;charset=UTF-8
Date: Wed, 20 Sep 2017 11:57:07 GMT
Expires: 0
Pragma: no-cache
Server: Apache-Coyote/1.1
Set-Cookie: CSRF-TOKEN=[some-token]; Path=/
Vary: Origin,Accept-Encoding
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: [some-token]
X-Xss-Protection: 1; mode=block
Content-Length: [some-length]
Strict-Transport-Security: max-age=15768000; includeSubDomains

2. Follow-up POST Request Header

POST /api/authentication HTTP/1.1
Host: [my-backend-host]
Connection: keep-alive
Content-Length: [some-length]
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/plain, */*
Origin: [my-frontend-host]
User-Agent: [Google-Chrome-User-Agent]
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: [my-frontend-host]
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4,de-CH;q=0.2,it;q=0.2
Cookie: [some-other-cookies]; CSRF-TOKEN=[same-token-as-in-the-previous-request]

This request should contain a CSRF header which would automatically be added if the cookie was accessible with JavaScript.

Lucania

Looks like this might be your answer: #14687269 – Crackpot

@Lucania Just to make sure, because you wrote "both domains" - In the secure deployment configuration, do both back-end and front-end run from the same domain only with a different port? (Like they both run on localhost and different port locally) If they run from different ones, the front-end won't be able to access other domains' cookies. – Floating

Please make sure you have not blocked third party cookies: https://mcmap.net/q/76642/-set-cookie-on-browser-with-ajax-request-via-cors – Loper

@Floating Thank you for your comment. I was actually thinking of using CORS to access an API from a completely different domain and accessing the CSRF token with JavaScript (which is stored in a cookie): e.g. https://example1.com is accessing https://example2.com. But thanks to your comment, I realized, that it is not possible to access the cookies of the API (example2.com) on the front-end (example1.com). For my case, this means, I have to transmit the CSRF token in the header of a server response instead of a cookie - or just use a reverse proxy. – Lucania

@GökhanKurt Thanks, but this was not the case. – Lucania

@Lucania Cool, I thought that might be the case, it's easy to get confused by these things :) I didn't think it will make much of a good SO answer, so I wrote it as a comment, but it's a shame to see that nice bounty goes to waste ;) – Floating

@Floating You can leave a short anwer with the content of your comment and refer to my answer and I'll give you the bounty. Because it was your comment which contained the actual correct answer :) – Lucania

Answer 1

In short, it is not possible to access cross-origin cookies, document.cookie can only access the current (or parent) domain cookies.

The hint for that being the root cause, was ssc-hrep3 mentioning "both domains" in his question.

It's very to easy to make that mistake when switching from a localhost deployment, using only different ports for back-end and front-end servers, to one that uses two different hosts. That will work locally, because cookies are shared across ports, and will fail when two different hosts are used. (Unlike some other CORS issues that will be also exposed locally)

See ssc-hrep3's answer for more information and a workaround.

Floating

"document.cookiecan only access the current domain cookies" is not exact truth... it can access parent domain coolies as well – Cockneyfy

@AndreyMuzalevsky Yeah, I was aiming for a very short simplified explanation. But I will add this point. – Floating

Answer 2

TL;DR: Read-access to cross-domain cookies is not possible. Adding the CSRF token to the response header would be a solution. Another solution to completely circumvent CORS & cross-domain requests would be to use a reverse proxy.

---

Problem

As stated in my question above, the JavaScript part of my front-end (e.g. https://example1.com is trying to access a non-HttpOnly cookie from my back-end on e.g. https://example2.com. To be able to access a remote API with JavaScript, I'm using CORS. This allows the requests to go through. I'm using withCredentials: true on the front-end side and Access-Control-Allow-Credentials: true on the back-end side. The Set-Cookie header then sets the cookie on the back-end origin and not on the front-end origin. Therefore, the cookie is neither visible in the DevTools nor in the document.cookie command in JavaScript.

Cookies, set on the back-end origin, are always part of a request to the back-end via CORS. I would, however, need access to the content of the CSRF cookie to add the token into the request header (to prevent CSRF attacks). As I found out, there is no way to read (or write) cookies from a different domain with JavaScript – no matter what CORS setting is used (see these StackOverflow answers: [1], [2]). The browser restricts access to the content of a cookie to same-domain origins.

Solutions

This leads to the conclusion, that there is no possibility to access the contents of a non-HttpOnly cookie of a different domain. A workaround for this issue would be to set the CSRF token into an additional, custom response header. Those headers can usually also not be accessed by a different domain. They can however be exposed by the back-end's CORS setting Access-Control-Expose-Headers. This is secure, as long as one uses a strictly limited Access-Control-Allow-Origin header.

Another workaround would be to use a reverse proxy, which circumvents the issues with CORS and cross-domain requests at all. Using such a reverse proxy provides a special path on the front-end, which will be redirected to the back-end (server-side). For example, calls to https://front-end/api are proxied to https://back-end/api. Because all requests from the front-end are made to the front-end proxy on the same domain, the browser treats every call as a same-domain request and cookies are directly set on the front-end origin. Drawbacks of this solution comprise potential performance issues because of another server being in-between (delays) and the cookies need to be set on two origins (login twice when directly accessing the back-end). Setting up a reverse proxy can be done with nginx, apache or also very easy by using http-proxy-middleware in Node.js:

var express = require('express');
var proxy = require('http-proxy-middleware');

var options = {
	target: 'https://[server]',
	changeOrigin: true,
	secure: true
};

var exampleProxy = proxy(options);
var app = express();

app.use('/api', exampleProxy);
app.use(express.static(__dirname + "/public"));
app.listen(process.env.PORT || 8080);

Lucania

Answer 3

1

You may need to add Access-Control-Allow-Headers header to allow passing of specific headers.

Please try to add following into your server response headers (OPTIONS method) for testing purposes

Access-Control-Allow-Headers: Content-Type, *

In production I recomend to limit headers as following (but I'm not 100% sure in correct header list, need to experiment here if it works)

Access-Control-Allow-Headers: Cookie, Set-Cookie

See this for the reference https://quickleft.com/blog/cookies-with-my-cors/

2

Another problem that you may experince is that you cookies will be set on that domain where your backend service located (not on the domain you querying from)

Please check this also

3

As an option of last problem - browser can prohibit setting cookie for domain b.xxx.com from request which comes from a.xxx.com

In this case you may try to set cookie on the parent domain xxx.com, so it will be available for your client side

Cockneyfy

Thanks! The issue was mainly, that I was using two different domains and I could not access the cookies of the back-end domain on the front-end (so your second point). – Lucania

@Lucania You can [set cookie for parent domain]( serverfault.com/questions/153409/…) in case your service and consumer are sharing same parent domain - this solution will work for you – Cockneyfy

@AndreyMuzalevsky Thanks! Unfortunately, this is not the case. I thought I could work around this issue with CORS, but as it showed, it is not possible to access cookies cross-domain. But thank you for your efforts! I really appreciate it. – Lucania

Answer 4

As you can read here, the XHR specification explictily disallows reading Set-Cookie. The best way to do it would be to pass information in a header instead of a cookie.

Duthie

I do not want to read Set-Cookie, but access the cookie in a normal way with document.cookie in JavaScript. This works with CORS on localbost but not in the above setting. The cookies themselves are not accessible but are sent along with the upcoming request. This is the expected behavior for HttpOnly cookies but not regular ones. – Lucania