Web is stateless

HTTP is a stateless protocol. You may use cookies and sessions to maintain the state of an application specific to an end user.

What are the differences between sessions and cookies?

Cookies

HTTP cookie (web cookie/ Internet cookie, browser cookie or simply cookie) is a small piece of data sent from a website and stored in the user's web browser while the user is browsing. If  programmer doesn’t assign an expiration date to the cookie, it is lost with browser close. These are In-memory cookies for the browser, on the other hand you may set expiration date for the cookie to make it Persistent cookie. Persistent cookie deems to be stored on the client side hard drive and retrieved on next visit of website based on expiration date set by server side..

Programmers may use Response object to create and set cookie values, and Request object to retrieve the values of cookies created during previous interaction. Cookies are associated with a website, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site (exception: see benefit section for Path property of Cookies).

Limitations:

1. The security of cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs. You should never store sensitive data in a cookie, such as user names, passwords, credit card numbers, and so on. Do not put anything in a cookie that should not be in the hands of a user or of someone who might somehow steal the cookie information. This also means, on server side you should safeguard server side logics with extra validations, when you are taking inputs from cookies. (Less secured than session)

2. Most browsers support cookies of up to 4096 bytes. This limit is applied to the name-value portion of the cookie only. (No size limits in session)

3. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined. So, you may have to create cookies with sub-keys, in case you are reaching the count limits. ( No count limit in sessions)

4. User has the rights to deny using cookies. As per Cookie Law, your website must inform visitors how you use cookies. Also, you must write a dummy cookie in your web application implementation and read on server side, to verify if current browser of user is supporting cookies. (Session is server side, so user can’t handle /control sessions)

5. User has the ways to clear cookies on his web browser, no matter what expiration time you mentioned. (User can’t clear sessions without exposed functionality given to user)

6. You must check for nonexistence of a cookie key in request object to avoid null reference errors. (But similar is also true for sessions too)

7. In the request object, you will not get the expiration date of the cookie, if you are too much concerned about expiration date; you need to reset it every time on server side. (Session timeout is controlled in web.config in .net apps)

Benefits:

1. You may limit the scope of specific cookie to specific folder of website by defining Path property of cookie.

2. You may set the Domain property of cookie to limit scope to a specific domain/sub-domain.

3. You may request a browser to delete a cookie by setting expiration date earlier than current time, say yesterday.

4. You may create a new cookie on server side with same name as existing cookie and send its value to client, to modify an existing cookie.

5. We will discuss later in this post, what are server side sessions and how they may get benefit from cookies.

Session

A session can be defined as server-side storage of information that is desired to persist throughout the user's interaction with the web site or web application. Dealing with sessions without cookies is a mess as described in benefits of cookies above. Web applications transmit session Ids from server side as cookie, so that during next request session id in next request may identify the session. Some older browsers do not support cookies or the user may disable cookies in the browser, in that case sessionId may be munged in the each href clickable on the page. This seems more unsecured to me than disabling cookies though.

Types of Session Implementation: Sessions may be implemented in-memory on server side (InProc session mode), using state server services (Aspnet_state.exe), SQL server or by custom providers in .Net applications and SQL Server session mode is a more reliable & secure session state management as per Jana (2009). In PHP based applications, you may edit php.ini and set the session.save_handler and use external DB to store sessions as per Waterson (2015). Possible values for save_handler in PHP could be files (default), mm, database and SQLLite. PHP provides a function that lets you override the default session mechanism by specifying the names of your own functions for taking care of the distinct tasks as per Shiflett (2004).

Benefits:

1. Easier to maintain user specific data across all the requests.

2. Kind of objects being stored are vast.

3. Much more secured and hidden from user as compared to cookies.

4. Under in-memory model, session data in a memory object of the current application domain. So accessing data is very fast and data is easily available.

5. There is not requirement of serialization to store data in InProc session mode.

6. In .Net Sessions may be handled at page level too. We may disable session or make it read-only on a specific page using EnableSessionSate property of page.

Limitations:

1. There is an overhead involved to serialize and de-serialize  objects in case of StateServer  and SQLServer session modes.

2. Under InProc session mode, If the worker process or application domain is recycled, all session data will be lost. We may want to switch to state services, external DB or custom provider here.

3. InProc session mode is the fastest, more session data and more users can affect performance, because of memory usage.

4. Under multiple server farm scenarios, InProc session mode is not used at all.

When might a developer choose one or the other?

First thing first, as defined in definition of session above, session needs cookie to be implemented for storing session Id at least. If a specific information need not be secured (as defined in  limitation 1 of cookie above), and the size is small, cookie may be chosen to store this information, e.g. cart items of the user, user preferences without login for next visit on the same site and so on. On the other hand, secured and heavy information is never passed on to client side cookies as defined in benefit 3 of session above.

Are there any privacy or security implications to using either?

Session objects are on server side, that does not mean they are fully secured, but for sure much more secured than cookies on client side they are. Sessions will be as much secure as you make them, but cookies don't qualify to be in this race as defined by limitation 1 of cookies. You may try to make session more secured by using external DB or use EnableSessionSate property of web pages to make them more secured in .Net.

What benefits do they provide to the developer that might override those privacy and security implications?

Cookies put less overhead on the server side, if the information need not be secured like tracking cookies, website usability etc. we may choose it. Detailed benefits and limitations of cookies as compared to sessions may be analyzed in Limitation/Benefit sections above.

References

Auger, R. (2011, January). Cross Site Scripting. Retrieved March 03, 2016, from http://projects.webappsec.org/w/page/13246920/Cross Site Scripting

Iain. (n.d.). Browser Cookie Limits. Retrieved March 03, 2016, from http://browsercookielimits.squawky.net/

Jana, A. (2009, January 23). Exploring Session in ASP.NET. Retrieved March 03, 2016, from http://www.codeproject.com/Articles/32545/Exploring-Session-in-ASP-Net

LassoSoft. (n.d.). Lasso Programming: Tutorial: Understanding Cookies and Sessions. Retrieved March 03, 2016, from http://www.lassosoft.com/Tutorial-Understanding-Cookies-and-Sessions

Microsoft. (n.d.). Maintaining Session State with Cookies. Retrieved March 03, 2016, from https://msdn.microsoft.com/en-us/library/ms526029(v=vs.90).aspx

Microsoft. (2011). ASP.NET Cookies Overview. Retrieved March 03, 2016, from https://msdn.microsoft.com/en-us/library/ms178194(v=vs.100).aspx

Optanon. (n.d.). The Cookie Law Explained. Retrieved March 03, 2016, from https://www.cookielaw.org/the-cookie-law/

Shiflett, C. (2004, December 14). Storing Sessions in a Database. Retrieved March 03, 2016, from http://shiflett.org/articles/storing-sessions-in-a-database

Waterson, K. (2015, May 8). Introduction To PHP Sessions. Retrieved March 03, 2016, from http://www.phpro.org/tutorials/Introduction-To-PHP-Sessions.html