What is safe is to do it right. It is to master the subject, to know all the possible vulnerabilities of each mechanism. Know when and how it can be used. It depends on each case.

Are you using SSL? This makes a difference in security.

Which is safer

Anyway, I prefer sessions because it is not stored in the browser. The cookie can be tampered with, caught. But depending on how it is used, it has no problems. Just never put sensitive information in a cookie .

There is controversy over whether to use a cookie to keep a user logged in or not, many websites do. In thesis is dangerous. But it is a calculated danger and the user's security is that it can be compromised, not the security of the web application. Obviously you can not make something secure that you do not have control of, so if it really is necessary, do not let the user "logged in" by a control mechanism in the browser.

A session can use a cookie to keep it active (it depends on the implementation, the current one uses). She takes care of doing what is necessary to keep him safe. It already has a proven security standard. It's a more abstract way of taking care of security. Of course it is still necessary to take some care. The session holds data on the server side, which is a huge advantage over pure cookies .

I see some people say to use cookies and not session . But it depends what it will be used for. People who have experience with it live using sessions. Of course they do it knowing how to use it, as I said right away.

You can use ASP.Net Identity which is another abstraction layer to get a session control mechanism (yes, it has a session control built into it), among other things.

In the background everything uses cookie , just choose the abstraction layer you want.

I would never say to use one or the other without knowing the specific case. I will not apply a general "good practice". Each mechanism has its utility, advantage and disadvantage. And mostly I would not say not to use something unless there is a clear fact not to use, if, for example, the supplier has become obsolete and gave a good reason not to use it anymore. This is not the case with the mechanisms mentioned in the question.

The specific subject on the functioning and difference between the two mechanisms has already been widely answered here in SOpt. The question does not ask and I will not go into details, after all she is more specific. For example: What's the difference between Sessions and Cookies .

Use ASPNET Identity to manage the authentication of your users. It already provides several security requirements and is super easy to work with.

The ideal is to use a cookie to write non-security information. For example, user preferences, last pages, or viewed products, when you were last on your site - for an access control meter, perhaps.

And if it is a web, DO NOT USE SESSION.

• Sessions are allocated in the IIS Pool: When the AppPool memory is recycled, its data stored in Session is released;
• Sessions are exclusive access: Whenever Session access is performed, every execution pipe is locked until access is terminated. So you can only have one access to the Session at a time. Imagine this with multiple connected users simultaneously.
• Session are not scalable: As it is allocated in AppPool, if hosted on scalable servers, this information will not be shared among other hosts. So if your app uses Session, you can not scale horizontally.

So we use Cache instead of Session. And that's also why there are several Cache solutions on the market today.

Just remember that Cache is shared by every application. So if you are going to cache a user's data, simply Cache["DadosDoUsuario" + UsuarioId] and be happy.

You can use the System.Web.Caching.Cache " per hour, and if you really need to invest in data in Cache, go to a RavenDB or Redis.

But Session? Say no to the Sessions.