在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1： 以下程式碼使用依賴整數的指令，因此不容易受到 SQL injection 弱點的攻擊，可用來建立並執行 SQL 查詢以搜尋符合特定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

問題是開發人員沒有考慮到所有可能的 ID 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 此資料用來指定位於 LINQ 查詢中主要關鍵字的值。
範例 1：以下程式碼執行 LINQ 查詢以搜尋符合指定識別碼 [1] 的清單。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化指令，避開中繼字元的使用且避免 SQL injection 的弱點，用來建立並執行 SQL 查詢以搜尋符合特定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

問題是開發人員沒有考慮到所有可能的 ID 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定資料庫名稱的值。

在以下情況會發生資料庫 Access Control 錯誤：

1.資料從一個不可信賴的來源進入程式。


2.此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式，避開中繼字元並防止 SQL injection 弱點，用來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

有人認為在行動環境中，典型的 Web 應用程式弱點 (例如資料庫 Access Control 錯誤) 不會產生影響，因為使用者為何會攻擊自己呢？但是請謹記，行動平台的本質是從多種來源下載，並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高，這必然會擴大行動應用程式的受攻擊面，將程序之間的通訊包括在內。

範例 2：以下程式碼改寫 Example 1 以適用於 Android 平台。

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不受信任的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源，Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性，並在使用框架驗證機制時提供支援證據的指標，以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序，Fortify Software 安全研發團隊提供了資料驗證專案範本，該範本會依據套用到其輸入來源的驗證機制，按資料夾對問題進行分組。

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1： 以下程式碼使用參數化陳述式，避開中繼字元並防止 SQL injection 弱點，用來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。 此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不受信任的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

在以下情況會發生資料庫存取控制錯誤：

1. 資料從一個不可信賴的來源進入程式。


2. 此資料用來指定位於 SQL 查詢中主要金鑰的值。
範例 1：以下程式碼使用參數化陳述式 (不但可避開中繼字元的使用，而且可以防止 SQL injection 弱點)，來建構並執行 SQL 查詢以搜尋符合指定識別碼的清單 [1]。此識別碼是從與目前驗證的使用者有關聯的所有清單中所選取。

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

問題是開發人員沒有考慮到所有可能的 id 值。雖然介面會產生屬於目前使用者的清單識別碼清單，但攻擊者可能略過此介面以要求任何想要的清單。因為此範例中的程式碼沒有檢查以確保使用者擁有存取所要求清單的權限，所以即使清單不屬於目前使用者，程式碼也會顯示所有清單。

現代的網路瀏覽器支援每個 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：在以下範例中，use-secure-cookie 屬性允許透過未加密的傳輸傳送 remember-me Cookie。

	<http auto-config="true">
        ...
        <remember-me use-secure-cookie="false"/>
	</http>

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

瀏覽器會自動將 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 屬性。

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 設為根內容路徑「/」，不過，這麼做會將 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 cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

假設攻擊者在 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 下毒攻擊。

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 模式。

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")