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.

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 cookie without setting the HttpOnly property.

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

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 code creates a cookie without setting the HttpOnly property.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

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 cookie without setting the httpOnly property.

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

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 cookie without setting the HttpOnly property.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

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 code creates a cookie without setting the HttpOnly property.

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

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 cookie without setting the HttpOnly property.

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

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
...

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.

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.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum. For example:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

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

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

Developers often set cookies to be the root context path "/", however, doing so exposes the cookie to all web applications on the same domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

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

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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 forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

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, the browser sends the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, attackers can perform a "Cookie poisoning attack" by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  cookie_options = {};
  cookie_options.path = '/';
  ...
  res.cookie('important_cookie', info, cookie_options);

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

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

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

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  setcookie("mySessionId", getSessionID(), 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 user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("sessionid", value)   # Path defaults to "/"
  return res
...

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

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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: Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

    Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))

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

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

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. 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:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

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

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

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

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.

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 parameter to Lax for session cookies.

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

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set the value of the SameSite attribute to Strict in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code sets the value of the SameSite attribute to Lax for session cookies.

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

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set session cookies with SameSiteStrictMode for the SameSite attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code enables SameSiteLaxMode in the SameSite attribute for session cookies.

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

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set the value of the SameSite attribute to Strict in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code sets the value of the SameSite attribute to Lax for session cookies.

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

The SameSite attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href and src attribute of tags such as link and iframe in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.
Set session cookies with Strict for the SameSite attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe, img, and form do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.

Example 1: The following code enables the Lax mode in the SameSite attribute for session cookies.

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