When should I use session variables instead of cookies?

Solution 1:

• Sessions are stored on the server, which means clients do not have access to the information you store about them. Session data, being stored on your server, does not need to be transmitted in full with each page; clients just need to send an ID and the data is loaded from the server.

• On the other hand, cookies are stored on the client. They can be made durable for a long time and would allow you to work more smoothly when you have a cluster of web servers. However, unlike sessions, data stored in cookies is transmitted in full with each page request.

• Avoid storing data in cookies

  • It can be seen, read and manipulated by the end user, or intercepted by those with nefarious intent. You can't trust any data in cookies, except for the "session_id".
  • It increases your bandwidth, if you add 1k of data per page request per user, that might increase your bandwidth by 10-15%. This is perhaps not costly from a $$ perspective, but it could be from a performance perspective. It effectively would decrease your bandwidth on a per server by 10-15%, i.e., it might cause you to need more servers.

• What you can store in session data depends on the amount of data and number of users you have. no_of_users * size_of_session_data must be less than the free memory available on your server.

Solution 2:

• Always use sessions
• Use cookies only if you need longer logged-in sessions - Then add a cookie with an encrypted user ID.

Solution 3:

Most of the time, session state is persisted using cookies. So it's not really a question of one or the other, but how to use them together.

Using your framework's session infrastructure may make things easier, but tracking state manually with cookies usually gives you finer grained control. The correct solution depends on what you're trying to accomplish.

Solution 4:

Cookies can persist longer than a single session. However, cookies may also be deleted by the user, or you may have a user whose browser does not accept cookies (in which case only a server-side session will work).

Solution 5:

Cookies are client-side, and sessions are server-side.

Use cookies for small pieces of data that you can trust the user with (like font settings, site theme, etc.) and for opaque IDs for server-side data (such as session ID). Expect that these data can be lost at any time and they can not be trusted (i.e. need to be sanitized).

Use session data for bigger data chunks (for many systems can store objects, data structures, etc.) and ones you have to trust - like authorization status, etc. In general, use session data for storing larger state data.

You can store things like authorization status in cookies too, if it's needed for GUI, caching, etc. - but never trust it and never rely on it being present. Cookies are easy to delete and easy to fake. Session data is much harder to fake, since your application controls it.