We're doing authentication by sending a JWT via an httpOnly cookie.
(client sends credentials, server answers with a token cookie, client attaches it to all subsequent requests).

Due to some constraints, we need to deploy backend and frontend services on different domains. Thus, our token cookie that worked wonderfully on localhost, got blocked by the browsers as a 3rd party cookie.

Is there any way to use httpOnly cookies to transfer the JWT between different domains?

Or is there any other way to do authentication when the BE and FE reside on different domains?

Session storage and local storage were recommended in this article:
but we would like to avoid it for their XSS vulnerability.

1 Answer 1


Local Storage shares basically the same security policy as cookies (ex: not allowing a domain to access data generated by another domain), so there's no reason to believe that local storage is less secure than cookies.

In case of a XSS vulnerability, your data will not be safe wether you store them in a cookie or in local storage:

  • if you store JWT in local storage, an attacker could steal it. (ex. grabbing data and sending them to a server for later use)

  • if you store JWT in a cookie, an attacker could USE it. (ex. a crafted XHR request that will fully impersonate the user)

So the problem would not be where you put your data, but the fact that XSS is a vulnerability that opens the door to a range of possible attacks and for that reason, it should be fixed.

Answering your question, you could move the JWT to an 'Authorization' header rather than a cookie: the logics basically remain the same, the client just needs to store the authorization response and use it in any request as an header, so the server will be able to read and validate them. (keep in mind that also Cookies are headers)

  • 1
    Agreed that both cookie and header storage are vulnerable, but protection against CSRF (the vulnerability in case of cookies) seems more reliable than against XSS (vulnerability for headers), since we have a lot of forms and user input fields. We do both, but attackers are creative :) and CSRF seems harder to achieve than XSS.
    – Ioanna
    Commented Apr 5, 2019 at 2:51
  • 1
    @n0idea I would argue that your remark about cookie being on the same level as local storage is misleading. XSS can USE anything to fully impersonate the user but a proper cookie (i.e. httpOnly) will make it harder for an attacker to STEAL it using XSS. This is a valid reason to use cookies instead of local or session storage for access tokens. Commented Apr 8, 2019 at 16:12
  • @MarkoVodopija my answer is strictly related to the question. If an attacker, exploiting an XSS vulnerability, successfully includes a malicious script into a website (example: a crafted XHR request) an HttpOnly cookie won't be of any help in terms of protection: the fact that he's using the access token but not stealing it is still a big issue and in some cases could also be worse, because the ability of executing a client-side script could help the attacker to impersonate the user with little to no effort.
    – n0idea
    Commented Apr 9, 2019 at 12:48
  • 1
    @n0idea Agreed, XSS is bad. I wanted to point out that there are considerations when choosing the right storage for token itself and for what threats you are protecting against (i.e. theft). There is a clear difference between a httpOnly cookie and local storage. You said there is not reason to believe that local storage is less secure than cookies. This is partially correct (cross domain aspect). OP is (indirectly) referring exactly to token theft using XSS and using local storage will not mitigate that. Linked article badly explains on what particular threat local storage is vulnerable. Commented Apr 9, 2019 at 13:25
  • 1
    @Ioanna You will not be able to use cookie and local storage is the only option. You will need to be aware that in case of XSS, you are open (among other things) to token theft. Commented Apr 15, 2019 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .