I am currently trying to build an authentication flow where the front end lives on one domain, say X.com and the backend lives on Y.com. I have implemented a refresh/access token system where when a user logs in with username and password and the backend returns a refresh token which is an http only cookie stored client side. The access token is generated from the refresh token and is stored in memory of the front end app.

Right now I feel confident that the access tokens are secure since they are stored in memory and they have a short life span. However I am concerned about the refresh token. I have heard that an http only token(secure:true, sameSite:"None") is still vulnerable to CSRF attacks. I can't set sameSite to Strict or lax because my front and backend live on different domains.

I was wondering what the general approach would be to prevent a CSRF attack given this scenario. I understand that no system can be completely impenetrable but there must be some accepted way to mitigate this type of risk.

PS: I have heard about passing another token (CSRF token) in the header of requests to refresh the access token. However this extra token would have to be stored in a cookie that is non-http only meaning that this would leave my site open to XSS attacks. I'm not sure if this is a better vulnerability to have to deal with than CSRF or not.

  • welcome - there's a couple of things going on here - but first, please clarify: the user browser connects to X.com for frontend ui, and X.com connects to Y.com? (in this case the refresh cookie is set and retrieved by X.com only, to recreate the access token it needs to access Y.com for data?) or, the user connects to Y.com directly for data? (in this case the browser connects to both X and Y.com directly, and provides cookies to both servers)
    – brynk
    Commented Jul 11 at 12:04
  • @brynk User types username and password in X.com. This data hits an endpoint of express server running on Y.com. This endpoint then runs authentication logic and then sets an http only cookie in the response and returns it. Now whenever another request is sent from X to Y the front end logic checks if there is an access token in memory. If there isn’t then it uses the refresh token to get one and then completes the original request to retrieve data. The refresh cookies is only used for one endpoint and that is to get an access token. However I think this refresh endpoint is vulnerable to CSRF. Commented Jul 13 at 16:42


You must log in to answer this question.