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.

Answer 1

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);

Answer 2

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.