Is it possible to set an HttpOnly Cookie from one domain to another subdomain

Question

I am pretty sure that the answer to my question is no, but I have been have a hard time finding an answer through official documentation or other posts here. Here is simple use case for some context:

1. Python backend web application (api.domain.com)
2. Frontend JavaScript SPA (app.domain.com)
3. post requests to api.domain.com/api/auth/login/ made from app.domain.com using axios with the correct username and password return a response with an access JWT token in the body and the response sets a refresh cookie with an HttpOnly flag [should fail, since I believe that the cookie cannot be set on app.domain.com from an API request to api.domain.com? -- this is my question]
4. the access token is stored in memory and passed with each API request
5. requests made to api.domain.com/api/auth/refresh/ are sent on a schedule to refresh the short-lived access token.

I typically host the frontend app and backend app on the same subdomain (app.domain.com) and do path-based routing with something like CloudFront or nginx, and this works well. For example, all requests starting with /api/* are sent to the backend, and all other requests are sent to the frontend app. Trying to use a separate subdomain for the API seems to fail no matter what options I use for setting the cookie on the server.

Can someone help me confirm that it is in fact not possible to set an HttpOnly cookie on a subdomain like app.domain.com from an API request hosted on api.domain.com? It would be great if anyone can also help me find where this could possibly be found in official documentation.

Searching for set httpOnly cookie across subdomains, I haven't found anything directly relevant. I also didn't find anything in these resources that directly answers my question:

https://owasp.org/www-community/HttpOnly

https://docs.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN

Answer 1

I had the exact same problem and it turned out there were three things going wrong:

• The JS code doing the request using Axios, an HTTP library which has a bug around cookie handling: https://github.com/axios/axios/issues/2149.

  The fix was to use plain fetch and specify credentials: "include" in the options. Without this option, cookies are not included in cross-domain requests.

• The server was not including the Access-Control-Allow-Credentials header in the response, which has to be set to true on both the login endpoint (for the Set-Cookie to be accepted and stored by the browser) and the refresh-session endpoint (for the cookie to be sent back, here the OPTIONS response is the relevant piece).

• I set Same-Site: Strict in the cookie attributes (and prefixed the Cookie name with __Host-) assuming this would allow the cookie to only be sent back to the same domain but it resulted in the cookie not being stored at all. Same-Site has to be None for the cookie to work in cross-origin requests at all and the __Host- thing also seems to block the cookie from being stored when it comes from a different host. Omitting the Domain cookie attribute should be enough to stop the cookie from being sent to other domains.

Answer 2

That has been my experience and is, from what I understand, an actual cross domain attack :). If you want to use HTTP only cookies for auth you need both services to be under the same domain. With the help of a friend I set this up with nginx locally (nginx.conf below in case others need it). Both the front end app and back end app are served out of the same domain so that the browser will manage the cookies correctly. The last location (location /sockjs-node) is to allow webpack to hot reload on save for development since this is a react app front end.

As an aside, you might want to re-think your token pattern. The one I'm following in Flask off of the documentation is an HTTPOnly Cookie with the JWT token and then a csrf_token as a cookie that's readable by JS. You send the csrf_token with each request as a header and it's also encoded in the JWT. Kind of a two factor auth for the JWT in addition to it's signature from the generator server.

You would want to replace hal with your local user.

# user  nginx;
user hal staff;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include mime.types;
    default_type application/octet-stream;
    #access_log /var/log/nginx/access.log;
    sendfile on;
    keepalive_timeout  65;
    server {
        client_max_body_size 15m;
        listen 80;
        server_name local.earthdawn.com;
        charset utf-8;
        # error_log /var/log/nginx/error.log debug;
        index index.html;
        autoindex on;
        # root "/Users/hal/Dev"; #this is for a root dir that you want to pull static files from
        # added by Erik 28-02-2020 - caching handled by the CDN
        add_header "Cache-Control" "max-age=0, no-cache, no-store, must-revalidate";
        add_header "Pragma" "no-cache";
        add_header "Expires" "-1";
       
        # frontend app forwarding
        location / {
            proxy_set_header X-Real-IP       $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://localhost:3000;
        }
        # api forwarding
        location /api {
            proxy_set_header X-Real-IP       $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://localhost:5000;
        }
        # allows hot reloading for react app
        location /sockjs-node {
            proxy_pass http://localhost:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
        }
    }
}