Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用依赖于整数的语句构建和执行 SQL 查询，因此不易受到 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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

        ...
        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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

2. 这个数据用来指定 LINQ 查询中主键的值。
示例 1：以下代码执行 LINQ 查询，该查询可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
例 1：以下代码用到一个参数化指令，这个指令转义了元字符，以防止 SQL injection 漏洞，并构建和执行一个 SQL 查询。该 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 查询。该 SQL 查询可以搜索与指定标识符 [1] 相匹配的清单。您可以从与当前授权用户关联的所有清单中选择该标识符。

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

...
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 应用程序漏洞（如 Database 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 用户执行审计过程，Fortify 软件安全研究团队开发了 Data Validation（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
例 1：以下代码用到一个参数化指令，这个指令转义了元字符，以防止 SQL injection 漏洞，并构建和执行一个 SQL 查询。该 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 用户执行审计过程，Fortify 软件安全研究团队开发了 Data Validation（数据验证）项目模板，该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。

2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

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

问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

数据库访问控制错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 数据用来指定 SQL 查询中主键的值。
示例 1： 以下代码将使用参数化语句，该语句会转义元字符，以防止 SQL Injection 漏洞，并构建和执行一个 SQL 查询。该 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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

Database access control 错误在以下情况下发生：

1. 数据从一个不可信赖的数据源进入程序。


2. 这个数据用来指定 SQL 查询中主键的值。
示例 1：以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语句，以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的所有清单中选择这些标识符。

	...
	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 值。虽然界面生成了属于当前用户的清单标识符列表，但是攻击者可以绕过这个界面，从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问所请求清单的权限，因此它会显示任何清单，即使此清单不属于当前用户。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。

示例：在下面的示例中，在未设置 Secure 属性的情况下，为响应添加了一个 Cookie。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或会话标识符，或带有 CSRF 标记，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。

示例 1：在下列示例中，use-secure-cookie 属性允许 remember-me Cookie 通过未加密的传输发送出去。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未将 Secure 属性设置为 true 的情况下，为响应添加了一个 Cookie。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未设置 Secure 标记的情况下，为响应添加了一个 Cookie。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接截取网络信息流对攻击者而言十分简单，因此通过 HTTP 发送 cookie（特别是具有会话 ID 的 cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 cookie 的 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 cookie。通过未加密的通道发送 cookie 将使其受到网络截取攻击，因此安全标记有助于保护 cookie 值的保密性。如果 cookie 包含私人数据或会话标识符，或带有 CSRF 标记，那么该标记尤其重要。
示例 1：以下代码会在未设置 Secure 标记的情况下将 cookie 添加到响应中。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 cookie 也会在随后的 HTTP 请求过程中被发送。攻击者随后可截取未加密的网络信息流（通过无线网络时十分容易），从而危及 cookie 安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未设置 Secure 标记的情况下，为响应添加了一个 Cookie。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

现今的 Web 浏览器支持每个 Cookie 都具有 Secure 标记。如果设置了该标记，那么浏览器只会通过 HTTPS 发送 Cookie。通过未加密的通道发送 Cookie 将使其受到 Network Sniffing 攻击，因此该 secure 标记有助于保护 Cookie 值的机密性。如果 Cookie 包含私人数据或带有会话标识符，那么该标记尤其重要。
示例 1：在下面的示例中，在未设置 Secure 标记的情况下，为响应添加了一个 Cookie。

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

如果应用程序同时使用 HTTPS 和 HTTP，但没有设置 Secure 标记，那么在 HTTPS 请求过程中发送的 Cookie 也会在随后的 HTTP 请求过程中被发送。通过未加密的无线连接监听网络通信对攻击者而言十分简单，因此通过 HTTP 发送 Cookie（特别是具有会话 ID 的 Cookie）可能会危及应用程序安全。

浏览器会自动将 Cookie 附加到对设置 Cookie 的站点发出的每个 HTTP 请求中。Cookie 可能存储敏感数据，例如会话 ID 和授权令牌，或者在会话期间对同一站点的不同请求之间共享的站点数据。攻击者可以通过从客户机上加载的第三方网站页面生成对已验证站点的请求来执行模拟攻击，因为浏览器会自动将 Cookie 附加到请求中。

SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 可能存储敏感数据，例如会话 ID 和授权令牌，或者在会话期间对同一站点的不同请求之间共享的站点数据。攻击者可以通过从客户机上加载的第三方网站页面生成对已验证站点的请求来执行模拟攻击，因为浏览器会自动将 Cookie 附加到请求中。

SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 可能存储敏感数据，例如会话 ID 和授权令牌，或者在会话期间对同一站点的不同请求之间共享的站点数据。攻击者可以通过从客户机上加载的第三方网站页面生成对已验证站点的请求来执行模拟攻击，因为浏览器会自动将 Cookie 附加到请求中。

SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 可能存储敏感数据，例如会话 ID 和授权令牌，或者在会话期间对同一站点的不同请求之间共享的站点数据。攻击者可以通过从客户机上加载的第三方网站页面生成对已验证站点的请求来执行模拟攻击，因为浏览器会自动将 Cookie 附加到请求中。

SameSite 属性限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 可能存储敏感数据，例如会话 ID 和授权令牌，或者在会话期间对同一站点的不同请求之间共享的站点数据。攻击者可以通过从客户机上加载的第三方网站页面生成对已验证站点的请求来执行模拟攻击，因为浏览器会自动将 Cookie 附加到请求中。

samesite 参数限制了 Cookie 的作用域，因此只有当请求是从第一方或同一站点上下文生成时，才会将 Cookie 附加到请求。这样有助于保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 攻击。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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。

开发人员通常将 Cookie 设置为可从根上下文路径“/”进行访问。这会使 Cookie 暴露在该域的所有 Web 应用程序下。由于 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 Poisoning 攻击”，创建自己范围过大的 Cookie，并覆盖 /MyForum 中的 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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 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 篡改攻击”，创建自己范围过大的 cookie，并覆盖 /MyForum 中的 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 poisoning 攻击，创建自己范围过大的 cookie，并覆盖来自 /MyForum 的 cookie。

SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 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 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者能够将一位毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含用于授权该用户的会话 Cookie 的请求，从而可以使攻击者获取有效授权，就像他们是用户一样。
将会话 Cookie 设置为 SameSite 属性的 SameSiteStrictMode，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。

示例 1：以下代码将对会话 Cookie 启用 SameSite 属性中的 SameSiteLaxMode。

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

SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 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 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者能够将一位毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含用于授权该用户的会话 Cookie 的请求，从而可以使攻击者获取有效授权，就像他们是用户一样。
将会话 Cookie 设置为 SameSite 属性的 Strict，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。

示例 1：以下代码将对会话 Cookie 启用 SameSite 属性中的 Lax 模式。

session.cookie_samesite=Lax

SameSite 属性保护 Cookie 免受 Cross-Site Request Forgery (CSRF) 等攻击。会话 Cookie 代表用户访问站点，以便用户可以执行授权操作。但是，浏览器会自动将 Cookie 与请求一起发送，因此用户和网站会隐式信任浏览器进行授权。攻击者可以滥用此信任，通过在攻击者控制的第三方网站页面中的 link 和 iframe 等标签的 href 和 src 属性中嵌入链接，代表用户向站点发出请求。如果攻击者将毫无戒备的用户引诱到他们控制的第三方站点，则攻击者可以发出自动包含具有用户授权的会话 Cookie 的请求。从而可通过用户授权使攻击者获得有效权限。
将会话 Cookie 设置为 SameSite 参数的 Strict，这将限制浏览器仅将 Cookie 附加到顶级导航时的请求或来自同一站点的请求。来自第三方站点的请求（通过 iframe、img 和 form 等各种标签中的链接）不含这些 Cookie，因此能阻止站点采取用户可能未授权的操作。

示例 1：以下代码将对会话 Cookie 启用 samesite 属性中的 Lax。

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