An HTTP cookie is a small piece of data that a server sends to the user's web browser. The browser may store it and send it back with later requests to the same server.
Cookies are mainly used for three purposes:
Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user's browser as well; the browser stores all the cookies separately.
Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store.
Browsers also impose limitations on how many cookies your site can store on the user's computer. 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.
After receiving an HTTP request, a server can send one or more Set-Cookie headers with the response. The cookie is usually stored by the browser, and then the cookie is sent with requests made to the same server inside a Cookie HTTP header. An expiration date or duration can be specified, after which the cookie is no longer sent. Additional restrictions to a specific domain and path can be set, limiting where the cookie is sent.
The Set-Cookie HTTP response header sends cookies from the server to the user agent. A simple cookie is set like this:
This shows the server sending headers to tell the client to store a pair of cookies:
HTTP/2.0 200 OK
Then, with every subsequent request to the server, the browser sends back all previously stored cookies to the server using the Cookie header.
GET /sample_page.html HTTP/2.0
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
The lifetime of a cookie can be defined in two ways:
Permanent cookies are deleted at a date specified by the Expires attribute, or after a period of time specified by the Max-Age attribute.
Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;
Set-Cookie: id=a3fWa; Max-Age=0
When an Expires date is set, the time and date are relative to the client the cookie is being set on, not the server.
Max-Age specifies the number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately.
If both Expires and Max-Age are set, Max-Age has precedence.
The following cookie is a session cookie, it was removed when the user shut down the system.
If your site authenticates users, it should regenerate and resend session cookies, even ones that already exist, whenever the user authenticates. This technique helps prevent session fixation attacks, where a third party can reuse a user's session.
There are a couple of ways to ensure that cookies are sent securely and are not accessed by unintended parties or scripts: the Secure attribute and the HttpOnly attribute.
Here is an example:
Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly
The Domain and Path attributes define the scope of the cookie: what URLs the cookies should be sent to.
The Domain attribute specifies which hosts are allowed to receive the cookie. If unspecified, it defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
For example, if Domain=example.org is set, then cookies are available on subdomains like developer.example.org.
The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories match as well.
For example, if Path=/docs is set, these paths match:
The SameSite attribute lets servers specify whether/when cookies are sent with cross-origin requests (where Site is defined by the registrable domain), which provides some protection against cross-site request forgery attacks (CSRF).
It takes three possible values: Strict, Lax, and None.
None specifies that cookies are sent on both originating and cross-site requests, but only in secure contexts (i.e. if SameSite=None then the Secure attribute must also be set).
If no SameSite attribute is set then the cookie is treated as Lax.
Set-Cookie: mykey=myvalue; SameSite=Strict
Note: Standard related to SameSite recently changed:
SameSite=Lax is the new default if SameSite is not specified. Previously the default was that cookies were sent for all requests.
Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context).
These are general rules on when to use Strict, Lax or Noneas values for SameSite:
© 2022 Digcode.com