現代的網路瀏覽器支援每個 Cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie 易使 Cookie 受到網路攔截攻擊，因此安全旗標有助於保持 Cookie 值的機密性。若 Cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。

範例 1：在以下範例中，Cookie 已建立，但未將 isSecure 參數設為 true。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 isSecure 參數，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量對攻擊者而言是稀鬆平常之事，而且透過 HTTP 傳送 Cookie (尤其是含階段作業 ID 的 Cookie) 可能會危及應用程式的安全。

現代的網路瀏覽器支援每個 cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。若 cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。

範例：在以下範例中，Cookie 已新增至回應，而未設定 Secure 屬性。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 cookie (尤其是含階段作業 ID 的 cookie) 可能會造成應用程式資料外洩。

現代的網頁瀏覽器支援每個 Cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie，易使 Cookie 受到網路攔截攻擊，因此安全旗標可維持 Cookie 值的機密性。如果 Cookie 包含隱私資料或階段作業識別碼，或附帶 CSRF 權杖，這將更為重要。
範例 1：以下程式碼將 Cookie 新增到回應中，而未設定 Secure 旗標。

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

若應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。

現代的網路瀏覽器支援每個 cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。若 cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。
範例 1：在以下範例中，Cookie 已新增至回應，而未將 Secure 屬性設定為 true。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 cookie (尤其是含階段作業 ID 的 cookie) 可能會造成應用程式資料外洩。

現代的網路瀏覽器支援每個 cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。若 cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。
範例 1：在以下範例中，Cookie 已新增至回應，而未設定 Secure 旗標。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 cookie (尤其是含階段作業 ID 的 cookie) 可能會造成應用程式資料外洩。

現代的網路瀏覽器支援每個 cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。若 cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。
範例 1：以下程式碼將 Cookie 新增到回應中，而未設定 Secure 旗標。

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

若應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。

現代的網路瀏覽器支援每個 cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 cookie。透過未加密的通道傳送 cookie，易使 cookie 受到網路攔截攻擊，因此安全旗標可維持 cookie 值的機密性。如果 Cookie 包含私人資料或階段作業識別碼，或附帶 CSRF 權杖，這將更為重要。
範例 1：以下程式碼將 Cookie 新增到回應中，而未設定 Secure 旗標。

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

若應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。隨後攻擊者可能會攔截未加密的網路流量，進而危及 Cookie，這在無線網路會更加容易。

現代的網頁瀏覽器支援每個 Cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie，易使 Cookie 受到網路攔截攻擊，因此安全旗標可維持 Cookie 值的機密性。若 Cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。
範例 1：在以下範例中，Cookie 已新增至回應，而未設定 Secure 旗標。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 Cookie (尤其是含階段作業 ID 的 Cookie) 可能會造成應用程式資料外洩。

現代的網頁瀏覽器支援每個 Cookie 都有 Secure 旗標。若已設定旗標，則瀏覽器僅會透過 HTTPS 傳送 Cookie。透過未加密的通道傳送 Cookie，易使 Cookie 受到網路攔截攻擊，因此安全旗標可維持 Cookie 值的機密性。若 Cookie 包含隱私資料或附帶階段作業識別碼，這將更為重要。
範例 1：在以下範例中，Cookie 已新增至回應，而未設定 Secure 旗標。

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

若您的應用程式同時使用 HTTPS 和 HTTP，但是未設定 Secure 旗標，則在後續的 HTTP 要求期間，也會傳送在 HTTPS 要求時所傳送的 Cookie。透過未加密的無線連線攔截網路流量，對攻擊者而言是稀鬆平常之事，所以透過 HTTP 傳送 Cookie (尤其是含階段作業 ID 的 Cookie) 可能會造成應用程式資料外洩。

所有主流瀏覽器均支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 HttpOnly 屬性。

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

瀏覽器支援防止用戶端指令碼存取 Cookie 的 HttpOnly Cookie 屬性。Cross-Site Scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證權杖。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 HttpOnly 屬性。

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

所有主流瀏覽器均支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 httpOnly 屬性。

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

所有主流瀏覽器均支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 HttpOnly 屬性。

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

瀏覽器支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 HttpOnly 屬性。

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

所有主流瀏覽器均支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立 Cookie，而不設定 HttpOnly 屬性。

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

所有主流瀏覽器均支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。
範例 1：以下程式碼會建立階段作業 Cookie，而未將 HttpOnly 參數設為 true。

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

瀏覽器支援防止用戶端 Script 存取 Cookie 的 HttpOnly Cookie 屬性。Cross-site scripting 攻擊通常會存取 Cookie，嘗試竊取階段作業識別碼或驗證標記。如果未啟用 HttpOnly，則攻擊者將更容易存取使用者 Cookie。

範例 1：以下設定配置明確設定了階段作業 Cookie，而未設定 HttpOnly 屬性。

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

瀏覽器會自動將 Cookie 附加到向網站提出設定 Cookie 的每一個 HTTP 要求。Cookie 可能儲存敏感資料，例如階段作業識別碼和授權權杖，或階段作業期間在相同網站的不同要求之間共用的網站資料。攻擊者可以藉由從用戶端電腦上載入的第三方網站頁面向經過驗證的網站產生要求來執行模擬攻擊，因為瀏覽器會自動將 Cookie 附加到要求中。

SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：

- Strict：設定為 Strict 時，Cookie 僅與最上層導覽的要求一起傳送。
- Lax：當設定為 Lax 時，Cookie 會從同一主機透過頂層導覽傳送，還有透過來自第三方網站的 GET 要求傳送，包括那些具有 iframe 或 href 標籤 (會連結至主機站點) 的要求。如果使用者點選連結，要求將會包含 Cookie。
- None：在為 Cookie 設定的路徑和網域範圍內，向網站發出的所有要求中都會傳送 Cookie。由於使用 POST 方法提交表單而產生的要求也會允許隨要求一起傳送 Cookie。

範例 1：以下程式碼停用階段作業 Cookie 的 SameSite 屬性。

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

瀏覽器會自動將 Cookie 附加到向網站提出設定 Cookie 的每一個 HTTP 要求。Cookie 可能儲存敏感資料，例如階段作業識別碼和授權權杖，或階段作業期間在相同網站的不同要求之間共用的網站資料。攻擊者可以藉由從用戶端電腦上載入的第三方網站頁面向經過驗證的網站產生要求來執行模擬攻擊，因為瀏覽器會自動將 Cookie 附加到要求中。

SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：

- Strict：設定為 Strict 時，Cookie 僅與最上層導覽的要求一起傳送。
- Lax：設定為 Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。
- None：在為 Cookie 設定的路徑和網域範圍內，向網站發出的所有要求中都會傳送 Cookie。由於使用 POST 方法提交表單而產生的要求也會允許隨要求一起傳送 Cookie。

範例 1：以下程式碼停用階段作業 Cookie 的 SameSite 屬性。

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

瀏覽器會自動將 Cookie 附加到向網站提出設定 Cookie 的每一個 HTTP 要求。Cookie 可能儲存敏感資料，例如階段作業識別碼和授權權杖，或階段作業期間在相同網站的不同要求之間共用的網站資料。攻擊者可以藉由從用戶端電腦上載入的第三方網站頁面向經過驗證的網站產生要求來執行模擬攻擊，因為瀏覽器會自動將 Cookie 附加到要求中。

SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：

- Strict：設定為 Strict 時，Cookie 僅與最上層導覽的要求一起傳送。
- Lax：當設定為 Lax 時，Cookie 會從同一主機透過頂層導覽傳送，還有透過來自第三方網站的 GET 要求傳送，包括那些具有 iframe 或 href 標籤 (會連結至主機站點) 的要求。例如，假設有一個第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。
- None：在為 Cookie 設定的路徑和網域範圍內，向網站發出的所有要求中都會傳送 Cookie。由於使用 POST 方法提交表單而產生的要求也會允許隨要求一起傳送 Cookie。

範例 1：以下程式碼停用階段作業 Cookie 的 SameSite 屬性。

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

瀏覽器會自動將 Cookie 附加到向網站提出設定 Cookie 的每一個 HTTP 要求。Cookie 可能儲存敏感資料，例如階段作業識別碼和授權權杖，或階段作業期間在相同網站的不同要求之間共用的網站資料。攻擊者可以藉由從用戶端電腦上載入的第三方網站頁面向經過驗證的網站產生要求來執行模擬攻擊，因為瀏覽器會自動將 Cookie 附加到要求中。

SameSite 屬性限制了 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。SameSite 屬性可以有以下三個值：

- Strict：設定為 Strict 時，Cookie 僅與最上層導覽的要求一起傳送。
- Lax：設定為 Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。
- None：在為 Cookie 設定的路徑和網域範圍內，向網站發出的所有要求中都會傳送 Cookie。由於使用 POST 方法提交表單而產生的要求也會允許隨要求一起傳送 Cookie。

範例 1：以下程式碼停用階段作業 Cookie 的 SameSite 屬性。

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

瀏覽器會自動將 Cookie 附加到向網站提出設定 Cookie 的每一個 HTTP 要求。Cookie 可能儲存敏感資料，例如階段作業識別碼和授權權杖，或階段作業期間在相同網站的不同要求之間共用的網站資料。攻擊者可以藉由從用戶端電腦上載入的第三方網站頁面向經過驗證的網站產生要求來執行模擬攻擊，因為瀏覽器會自動將 Cookie 附加到要求中。

samesite 參數會限制 Cookie 的範圍，所以只會在要求是從第一方或相同網站環境產生時，才會附加到要求。這有助於防範來自 Cross-Site Request Forgery (CSRF) 攻擊者的 Cookie。samesite 參數可以有以下三個值：

- Strict：設定為 Strict 時，Cookie 僅與最上層導覽的要求一起傳送。
- Lax：設定為 Lax 時，Cookie 會與來自同一主機的最上層導覽以及從第三方網站發起到主機的 GET 要求一起傳送。例如，假設第三方網站使用 iframe 或 href 標籤來連結至主機網站。如果使用者點選連結，要求將會包含 Cookie。
- None：在為 Cookie 設定的路徑和網域範圍內，向網站發出的所有要求中都會傳送 Cookie。由於使用 POST 方法提交表單而產生的要求也會允許隨要求一起傳送 Cookie。

範例 1：以下程式碼停用階段作業 Cookie 的 SameSite 屬性。

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

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 弱點。 任何已向 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 Cookie 的風險。

除了讀取 Cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立路徑範圍過大的 Cookie，藉此執行可從 secure.example.com 覆寫 Cookie 的 Cookie Poisoning 攻擊。

開發人員通常會將 cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：想像您已經在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域 ".example.com" 設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 弱點。任何已向 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 Cookie 的風險。

除了讀取 Cookie 之外，攻擊者還可以使用 insecure.example.com 來自行建立範圍過大的 Cookie，藉此執行可從 Secure.example.com 覆寫 Cookie 的「Cookie 破壞攻擊」。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

除了讀取 cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-site scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

除了讀取 cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定工作階段 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-site scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

除了讀取 cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：想像您已在 http://secure.example.com/ 上部署安全的應用程式，且當使用者登入時，應用程式以 ".example.com" 網域設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

除了讀取 Cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立過大範圍的 Cookie，藉此執行可從 secure.example.com 覆寫 Cookie 的「Cookie 破壞攻擊」。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1： 想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 弱點。 任何已向 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 Cookie 的風險。

除了讀取 Cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立路徑範圍過大的 Cookie，藉此執行可從 secure.example.com 覆寫 Cookie 的 Cookie Poisoning 攻擊。

開發人員通常會將 Cookie 設為在基礎網域 (如「.example.com」) 內啟用。這會將 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定階段作業 ID Cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-Site Scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

除了讀取 cookie 之外，攻擊者還有可能使用 insecure.example.com 來自行建立過大範圍的 cookie，藉此執行可從 secure.example.com 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將 Cookie 設為可從根內容路徑 (「/」) 存取。此舉會將 cookie 揭露給網域上所有的Ｗeb 應用程式。由於 cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID Cookie。例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite 建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 之論壇使用者的帳戶安全。

除了讀取 Cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 Cookie，藉此執行可從 /MyForum 覆寫 Cookie 的 Cookie 破壞攻擊。

開發人員通常會將 Cookie 設為根內容路徑「/」，不過，這麼做會將 Cookie 揭露給同一個網域名稱的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 cookie，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將 cookie 設為可從根內容路徑 (「/」) 存取。此舉會將 cookie 揭露給網域上所有的Ｗeb 應用程式。由於 cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共享 cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
假設您已經在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID Cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite 建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當論壇使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 之論壇使用者的帳戶安全。

除了讀取 Cookie 之外，攻擊者還可以使用 /EvilSite 來自行建立範圍過大的 Cookie，藉此執行可從 /MyForum 覆寫 Cookie 的「Cookie 破壞攻擊」。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 cookie，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 cookie，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定工作階段 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite 建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 cookie，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 Cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 Cookie，藉此執行可從 /MyForum 覆寫 Cookie 的「Cookie 破壞攻擊」。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1： 想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID Cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 Cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立路徑範圍過大的 Cookie，藉此執行可從 /MyForum 覆寫 Cookie 的 Cookie Poisoning 攻擊。

開發人員通常會設定「可從根內容路徑 (「/」) 存取 Cookie」，不過，這麼做會將 Cookie 揭露給網域上的所有 Web 應用程式。由於 Cookie 通常具有敏感資訊 (如階段作業識別碼)，因此在應用程式間共用 Cookie 可能會使一個應用程式中出現弱點，進而對另一個應用程式造成危害。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定階段作業 ID cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，瀏覽器會將由 /MyForum 設定的 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 ID，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

除了讀取 cookie 之外，攻擊者還有可能使用 /EvilSite 來自行建立過大範圍的 cookie，藉此執行可從 /MyForum 覆寫 cookie 的 Cookie 下毒攻擊。

開發人員通常會將階段作業 Cookie 設為基礎網域 (如「.example.com」)。這會將階段作業 Cookie 揭露給基礎網域及任何子網域上的所有 Web 應用程式。在應用程式間共享 Cookie 可能會使一個應用程式中的弱點，對另一個應用程式造成危害。

範例 1：
想像您已在 http://secure.example.com/ 部署安全的應用程式，且當使用者登入時，應用程式以網域「.example.com」設定工作階段 cookie。

例如：

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

假設您在 http://insecure.example.com/ 有另一個較不安全的應用程式，且它含有 Cross-site scripting 的弱點。任何已受 http://secure.example.com 驗證的使用者在瀏覽 http://insecure.example.com 時，會造成向 http://secure.example.com 暴露其階段作業 cookie 的風險。

開發人員通常會將階段作業 Cookie 設為根內容路徑 (「/」)。這麼做會將 Cookie 揭露給同一個網域名稱的所有 Web 應用程式。洩漏階段作業 Cookie 會造成帳戶洩漏，因為攻擊者可能使用網域中任一個應用程式的弱點來竊取階段作業 Cookie。

範例 1：
想像您已在 http://communitypages.example.com/MyForum 部署論壇應用程式，且當使用者登入論壇時，應用程式以路徑「/」設定工作階段 cookie。

例如：

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

假設攻擊者在 http://communitypages.example.com/EvilSite建立另一個應用程式，並在此論壇中張貼連至此網站的連結。當該論壇的使用者按一下此連結時，該使用者的瀏覽器會將由 /MyForum 設定的階段作業 Cookie 傳送到在 /EvilSite 執行的應用程式。透過竊取階段作業 Cookie，攻擊者便可危及瀏覽 /EvilSite 的任何論壇使用者之帳戶安全。

SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。
在工作階段 Cookie 中，將 SameSite 屬性的值設定為 Strict。這會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自相同網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。

範例 1：以下程式碼在工作階段 Cookie 中，將 SameSite 屬性設定為 Lax。

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

SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。
設定階段作業 Cookie，使其包含設為 SameSiteStrictMode 的 SameSite 屬性，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。

範例 1：以下程式碼會在 SameSite 屬性中針對工作階段 Cookie 啟用 SameSiteLaxMode。

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

SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。
在工作階段 Cookie 中，將 SameSite 屬性的值設定為 Strict。這會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自相同網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。

範例 1：以下程式碼在工作階段 Cookie 中，將 SameSite 屬性設定為 Lax。

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

SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie，藉此有效地授權攻擊者，就好像他們是使用者一樣。
設定階段作業 Cookie，使其包含設為 Strict 的 SameSite 屬性，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。

範例 1：以下程式碼在階段作業 Cookie 的 SameSite 屬性中啟用 Lax 模式。

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

SameSite 屬性可防範來自 Cross-Site Request Forgery (CSRF) 等攻擊的 Cookie。階段作業 Cookie 代表網站的使用者，以便使用者可以執行授權的動作。但是，瀏覽器會自動隨要求傳送 Cookie，因此使用者和網站會間接信任瀏覽器來進行授權。攻擊者可以濫用這種信任，並藉由在攻擊者控制之第三方網站頁面中的 link 和 iframe 等標籤的 href 和 src 屬性中嵌入連結，來代表使用者向網站發出要求。如果攻擊者能將毫無戒心的使用者引誘到他們控制的第三方網站，則攻擊者便可發出要求來自動包含授權使用者的階段作業 Cookie。這可以有效為攻擊者提供使用者授權的存取權限。
在 SameSite 參數中，將階段作業 Cookie 設為 Strict，會限制瀏覽器僅將 Cookie 附加至最上層導覽或源自同一網站的要求。透過 iframe、img 和 form 等各種標籤中的連結，從第三方網站發起的要求沒有這些 Cookie，因此會阻止網站採取使用者可能未授權的動作。

範例 1：以下程式碼會在 samesite 屬性中針對工作階段 Cookie 啟用 Lax。

  response.set_cookie("cookie", value="samesite-lax", samesite="Lax")

多數網路程式撰寫環境預設為建立非持續性 Cookie。這些 Cookie 僅存放在瀏覽器記憶體中 (不會寫入磁碟)，當瀏覽器關閉時便會遺失。程式設計師可指定 Cookie 在瀏覽器階段作業內持續留存，直到未來的某一天為止。這一類 Cookie 將寫入磁碟並留存在瀏覽器階段作業間，電腦重新啟動也不會遺失。

若隱私資訊儲存在持續性 Cookie 中，攻擊者將有更多的時間來竊取此資料 - 尤其是因為持續性 Cookie 通常設為在很久之後才過期。持續性 Cookie 通常在使用者與網站互動時做為使用者設定檔。視對此追蹤資料所做的準備而定，可使用持續性 Cookie 來侵犯使用者的隱私。

範例 1：下列程式碼將 Cookie 設為 10 年後過期。

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

多數網路程式撰寫環境預設為建立非持續性 cookie。這些 cookie 僅駐在瀏覽器記憶體中 (不會寫入磁碟)，當瀏覽器關閉時便將遺失。程式設計師可指定 cookie 在瀏覽器階段作業內持續留存，直到未來的某一天為止。這一類 cookie 將寫入磁碟並留存在瀏覽器階段作業間，電腦重新開機也不會遺失。

若隱私資訊儲存在持續性 cookie 中，攻擊者將有更多的時間來竊取此資料 - 尤其是因為持續性 cookie 通常設為在很久之後才過期。持續性 cookie 通常在使用者與網站互動時做為使用者設定檔。視對此追蹤資料所做的準備而定，可使用持續性 cookie 來侵犯使用者的隱私。
範例：下列程式碼將 cookie 設為 10 年後過期。

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