Cookie Security

What is a “Cookie”?

An HTTP Cookie is a small piece of data sent by a server to the user’s web browser. The browser can store this data and send it back to the same server with the next HTTP request. It is often used to check that two requests come from the same browser, or to allow the user to log in, and remembers state information for the stateless HTTP protocol.

Cookies are mainly used for three purposes:

Session management

Login transactions, shopping carts (in e-commerce applications), game scores or other elements that the server needs to remember.

Personalization

User preferences, themes and other settings.

Traceability

Recording and analyzing user behavior.

Cookies used to be used to store user information on the client side. Today, it is recommended to use modern storage APIs to store user information. Cookies are sent to the server with every HTTP request, which can reduce performance.

Cookie Generation

A server receiving an HTTP request can send the Set-Cookie HTTP header information. Cookies are usually stored in browsers and sent in the Cookie HTTP header in a request to the same server. Cookies can be set with an expiration date or duration, and expired Cookies will not be sent to the server. In addition, restrictions can be made for a specific domain and path by limiting the path where the cookie is sent.

Set-Cookie and Cookie HTTP headers

The Set-Cookie HTTP header contains the Cookie value sent from the server to the client and tells the client to store the Cookie.

An example Set-Cookie header;

Set-Cookie: Test=testing

For each new request made after this HTTP response from the server, the browser sends the previously stored Cookie header information to the server.

GET / HTTP/1.1

Host: www.testsite.com

Cookie: Test=testing

Session Cookies

The Cookie created above is a session Cookie value and is deleted when the client is closed because it does not specify an Expire or Max-Age value. However, web browsers can use session restoration, which makes most session cookies persistent as if the browser had never closed.

Persistent Cookies

Instead of being deleted when the client is closed, persistent cookies are deleted at the specific date and time.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Secure and HttpOnly Cookies

A Cookie with a Secure statement can only be sent to the destination server over the HTTPS protocol. Even if Secure is included, sensitive information should never be stored in Cookies.

To help mitigate Cross-Site Scripting (XSS) attacks, Cookies can be marked HttpOnly. A Cookie value marked as HttpOnly cannot be accessed by client-side scripting languages.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Cookie’s field of activity

Domain and Path directives determine the fields of activity of cookies (to which addresses the cookies will be sent).

The Domain directive specifies the domains that can receive the corresponding Cookie. If not specified, it defaults to the host of the current document location, excluding subdomains. If specified, subdomains are always included.

For example, if Domain=mozillla.org is specified, subdomains such as developer.mozillla.org will also have their respective Cookies included.

The Path directive specifies a URL path that must be present in the requested URL to send the Cookie value. The %x2F (“/”) character is considered a directory separator and will also match subdirectories.

For example, if Path=/docs is specified, the following URL paths will also match:

· /docs

· /docs/Web

· /docs/Web/http

The SameSite attribute allows servers to determine if/when to send cookies via cross-site requests (where Site is defined by the registrable domain and schema: http or https). This provides some protection against cross-site request forgery attacks (CSRF). The SameSite attribute can take the following three possible values:

· Strict

· Lax

· None

With Strict, the Cookie is only sent to the origin site. With the Lax attribute, the Cookie is allowed to be sent on some cross-site requests. Cookies with SameSite=None are specially marked for use in third-party contexts. By requiring SameSite=None cookies to be Secure (i.e., if SameSite=None, the Secure attribute must also be set), users are protected by default from attacks on their credentials that could compromise their privacy. Furthermore, insecure embeds are a risk to users’ privacy and security.
If the SameSite attribute is not set, the cookie defaults to Lax.