Developers often set session cookies to be a base domain such as ".example.com". This exposes the session cookie to all web applications on the base domain and any sub-domains. Sharing session cookies across applications can lead to a vulnerability in one application causing a compromise in another.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session cookie with the domain ".example.com" when users log in.

For example:

session_set_cookie_params(0, "/", ".example.com", true, true);

Suppose you have another less secure application at http://insecure.example.com/ and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

Developers often set session cookies to be the root context path ("/"). This exposes the cookie to all web applications on the same domain. Leaking session cookies can lead to account compromises because an attacker may steal the session cookie using a vulnerability in any of the applications on the domain.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session cookie with the path "/" when users log in to the forum.

For example:

session_set_cookie_params(0, "/", "communitypages.example.com", true, true);

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a forum user clicks this link, their browser will send the session cookie set by /MyForum to the application running at /EvilSite. By stealing the session cookie, the attacker can compromise the account of any forum user that browsed to /EvilSite.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/, and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

Suppose you have another, less secure, application at http://insecure.example.com/ and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from Secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a "Cookie poisoning attack" by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1: Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

Developers often set cookies to be active across a base domain such as ".example.com". This exposes the cookie to all web applications on the base domain and any sub-domains. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Suppose you have a secure application deployed at http://secure.example.com/ and the application sets a session ID cookie with the domain ".example.com" when a user logs in.

For example:

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Suppose you have another, less secure, application at http://insecure.example.com/, and it contains a cross-site scripting vulnerability. Any user authenticated to http://secure.example.com that browses to http://insecure.example.com risks exposing their session cookie from http://secure.example.com.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using insecure.example.com to create its own overly broad cookie that overwrites the cookie from secure.example.com.

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a session cookie without setting the HttpOnly flag to true.

session_set_cookie_params(0, "/", "www.example.com", true, false);

Browsers support the HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without HttpOnly enabled, attackers have easier access to user cookies.

Example 1: The following settings configuration explicitly sets the session cookies without setting the HttpOnly property.

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...
SESSION_COOKIE_HTTPONLY = False
...

A persistent session cookie remains valid even after a user closes the browser and is often used as part of a "Remember Me" feature. Consequently, a persistent session cookie allows users to remain authenticated to an application even after closing their browsers - assuming they did not explicitly log out. This means the next person that opens the browser will automatically be logged in as the last user. Unless your application is deployed in a controlled environment where users are not allowed to log on from shared machines, it is possible for attackers to compromise your users' accounts even after they have closed their browsers.
Example 1: The following code sets the session cookie to expire in 10 years.

session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, and the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.

Example 1: In the following example, a cookie is created without setting the isSecure parameter to true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

If your application uses both HTTPS and HTTP but does not set the isSecure parameter, cookies sent during an HTTPS request are also sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, and sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.

Example 1: In the following example, a cookie is added to the response without setting the Secure property.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or session identifiers, or carries a CSRF token.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure property to true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or session identifiers, or carries a CSRF token.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: In the following example, a cookie is added to the response without setting the Secure flag.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: A configuration that results in the session cookie being added to the response without setting the Secure flag.

...
<configuration>
   <system.web>
   <authentication mode="Forms">
      <forms requireSSL="false" loginUrl="login.aspx">
      </forms>
   </authentication>
   </system.web>
</configuration>
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: The following code adds a cookie to the response without setting the Secure flag.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data, session identifiers, or carries a CSRF token.
Example 1: The following configuration entry does not explicitly set the Secure bit for session cookies.

...
MIDDLEWARE = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.

Example 1: The following code sets a cookie to expire in 10 years.

...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    cookie.Expires = DateTime.Now.AddYears(10);;

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and device restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

    ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Most web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

setcookie("emailCookie", $email, time()+60*60*24*365*10);

Most web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
  return res
...

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and computer restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))

Most Web programming environments default to creating non-persistent cookies. These cookies reside only in browser memory (they are not written to disk) and are lost when the browser is closed. Programmers can specify that cookies be persisted across browser sessions until some future date. Such cookies are written to disk and survive across browser sessions and device restarts.

If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Example 1: The following code sets a cookie to expire in 10 years.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true,
    NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code sets the SameSite attribute to None for session cookies.

...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie such that it will only be attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Example 1: The following code disables the SameSite attribute for session cookies.

    ...
    CookieOptions opt = new CookieOptions()
    {
        SameSite = SameSiteMode.None;
    };
    context.Response.Cookies.Append("name", "Foo", opt);
    ...

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

c := &http.Cookie{
  Name: "cookie",
  Value: "samesite-none",
  SameSite: http.SameSiteNoneMode,
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appends the cookie to the request.

The SameSite attribute limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originating from third-party sites, including those that have either iframe or href tags that link to the host site. For example, suppose there is a third-party site that has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

app.get('/', function (req, res) {
    ...
    res.cookie('name', 'Foo', { sameSite: false });
    ...
}

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The SameSite attribute limits the scope of the cookie such that it will only be attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.

Example 1: The following code disables the SameSite attribute for session cookies.

ini_set("session.cookie_samesite", "None");

Browsers automatically append cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data such as session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.

The samesite parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The samesite parameter can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top-level navigation.
- Lax: When set to Lax, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe or href tags that link to the host site. If a user follows the link, the request will include the cookie.
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with the request.

Example 1: The following code disables the SameSite attribute for session cookies.

  response.set_cookie("cookie", value="samesite-none", samesite=None)

The SameSite attribute protects cookies from Cross-Site Request Forgery (CSRF) attacks. The browser automatically appends cookies to every HTTP request made to the site that sets the cookie. Cookies might store sensitive data like session ID and authorization token or site data that is shared between different requests to the same site during a session. An attacker can perform an impersonation attack by generating a request to the authenticated site from a third-party site page loaded on the client machine because the browser automatically appended the cookie to the request.
The SameSite attribute on a cookie allows sites to control that behaviour and prevents browsers from appending the cookie to request if the request is generated from a third-party site page load. The SameSite attribute can have the following three values:

- Strict: When set to Strict, cookies are only sent along with requests upon top level navigation.
- Lax: When set to Lax, cookies are sent with top level navigation from the same host as well as GET requests originated to the host from third-party sites (for example, in iframe, link, href, and so on and the form tag with GET method only).
- None: Cookies are sent in all requests made to the site within the path and domain scope set for the cookie. Requests generated due to form submissions using the POST method are also allowed to send cookies with request.
Cookies that have the SameSite attribute with the value of None must be set with the Secure attribute otherwise the browser rejects the cookies. Additionally, a few specific browser versions reject the SameSite cookie with the None value for example, Chrome versions 51 to 66, versions of the UC Browser on Android prior to version 12.13.2, versions of Safari and embedded browsers on macOS 10.14, and all browsers on iOS 12 reject cookies set with SameSite=None. A suggested workaround for this issue is to set an alternate cookie with a prefix or suffix such as Legacy appended to cookiename. Sites can look for this legacy cookie if it does not find a cookie that was set with SameSite=None.