currently I'm working on a NestJs backend. I have already implemented the auth feature with jwt (access and refresh) stored in cookies. Originally I sent the jwt by the standard Bearer token way in the header. But I read, that storing tokens in the frontend in the local or session storage isn't recommended, that's why I switched to cookies.

The settings for cookies are the following:

  • httpOnly: true
  • secure: true
  • sameSite: strict

The frontend is a SPA written in Angular and there won't be any links to the frontend on any other sites and I plan to host backend and frontend on the same domain, that's why I choosed sameSite: strict.

Do I need in this case any protection against csrf attacks? From what I read I would say not, but maybe I overlooked something.

In case I would choose another sameSite strategy, like lax or none, then I will need to implement some kind of csrf protection (f. e. with tokens), right?

I also read this and I'm now a bit confused.

What I would like to achieve is, that my system (backend and frontend) is protected against any kind of security risks. But reading on the net, I have the feeling, if I implement technology1, I can avoid attack1, but not attack2, and if I implement technology2 I can avoid attack2, but not attack1.

Why isn't out there some kind of security best practices/guidlines, which say, if you want to protect your system against everything, then do this? I accept, each system has it's own characteristics and if some technology fits to one system, it doesn't means, that it fits to an other. But there should be exist some kind of general rules.

  • I think the important part is making sure no GET requests can do anything bad... (changing/deleting/creating data) I believe "Remember me" type cookies can be set same-site lax or none. I believe session cookies should always be same-site strict, http only, secure. I did say "think", and "believe", though, so... hopefully someone else will chime in here. Nov 1, 2023 at 20:27
  • also make sure that after login a new session is created to prevent session fixation attacks. If you do start a session before login (there are certain cases where that might be necessary for anti-csrf), make sure that a new one is created after logging in. Nov 2, 2023 at 16:46
  • A strict session cookie forces already logged-in users to interact with your site before their session is resumed. (Note that an HTML-based redirection already suffices, see here). While that prevents against CSRF attacks, it also prevents users from navigating to your site just to see their data. A lax session cookie combined with a CSRF protection token might therefore be preferable (see here). Nov 17, 2023 at 16:04


You must log in to answer this question.

Browse other questions tagged .