There are two ways that session state can store the unique ID that associates the client with a server session: by storing an HTTP cookie on the client or by encoding the session ID in the URL. Storing the session ID in the cookie is more secure but requires the client browser to support cookies.

For applications that allow clients that do not support cookies, such as a variety of mobile devices, the session ID may be stored in the URL. The URL option has several drawbacks. It requires that the links on the site be relative and that the page be redirected at the beginning of the session with new query-string values, and it exposes the session ID right in the query string, where it can be picked up for use in a security attack.

You are encouraged to use the cookieless mode only if you need to support clients that lack cookie support.

Session state also supports two additional options: System.Web.HttpCookieMode.UseDeviceProfile and System.Web.HttpCookieMode.AutoDetect. The former enables the session-state module to determine what mode (cookie or cookieless) is used on a per-client basis based on the browser capabilities. The System.Web.HttpCookieMode.AutoDetect option performs a handshake with the browser to verify whether a cookie may be stored, and therefore requires an additional request to make the determination. If you need to support cookieless clients, strongly consider using System.Web.HttpCookieMode.UseDeviceProfile to generate cookieless URLs only for clients that require them.