实用，完整的HTTP cookie指南

时间 2020-08-26

原文原文链接

做者：valentinog
译者：前端小智
来源：valentinog

点赞再看，微信搜索 【大迁世界】 关注这个没有大厂背景，但有着一股向上积极心态人。本文 GitHub https://github.com/qq44924588... 上已经收录，文章的已分类，也整理了不少个人文档，和教程资料。

Web 开发中的 cookie 是什么?

cookie 是后端能够存储在用户浏览器中的小块数据。 Cookie 最多见用例包括用户跟踪，个性化以及身份验证。html

Cookies 具备不少隐私问题，多年来一直受到严格的监管。前端

在本文中，主要侧重于技术方面：学习如何在前端和后端建立，使用 HTTP cookie。python

后端配置

后端示例是Flask编写的。若是你想跟着学习，能够建立一个新的Python虚拟环境，移动到其中并安装Flaskgit

mkdir cookies && cd $_

python3 -m venv venv
source venv/bin/activate

pip install Flask

在项目文件夹中建立一个名为flask app.py的新文件，并使用本文的示例在本地进行实验。github

谁建立 cookies ?

首先，cookies 从何而来？谁建立 cookies ？web

虽然可使用document.cookie在浏览器中建立 cookie，但大多数状况下，后端的责任是在将响应客户端请求以前在请求中设置 cookie。数据库

后端是指能够经过如下方式建立 Cookie：json

后端实际应用程序的代码(Python、JavaScript、PHP、Java)
响应请求的Web服务器（Nginx，Apache）

后端能够在 HTTP 请求求中 Set-Cookie 属性来设置 cookie，它是由键/值对以及可选属性组成的相应字符串：flask

Set-Cookie: myfirstcookie=somecookievalue

何时须要建立 cookie？这取决于需求。后端

cookie 是简单的字符串。在项目文件夹中建立一个名为flask_app.py的Python文件，并输入如下内容：

from flask import Flask, make_response

app = Flask(__name__)


@app.route("/index/", methods=["GET"])
def index():
    response = make_response("Here, take some cookie!")
    response.headers["Set-Cookie"] = "myfirstcookie=somecookievalue"
    return response

而后运行应用程序:

FLASK_ENV=development FLASK_APP=flask_app.py flask run

当该应用程序运行时，用户访问http://127.0.0.1:5000/index/，后端将设置一个具备键/值对的名为Set-Cookie的响应标头。

（127.0.0.1:5000是开发中的 Flask 应用程序的默认侦听地址/端口）。

Set-Cookie标头是了解如何建立cookie的关键：

response.headers["Set-Cookie"] = "myfirstcookie=somecookievalue"

大多数框架都有本身设置 cookie 的方法，好比Flask的set_cookie()。

如何查看 cookies ？

访问http://127.0.0.1:5000/index/后，后端将在浏览器中设置cookie。要查看此cookie，能够从浏览器的控制台调用document.cookie：

或者能够在开发人员工具中选中Storage选项卡。单击cookie,会看到 cookie 具体的内容：

在命令行上，还可使用curl查看后端设置了哪些 cookie

curl -I http://127.0.0.1:5000/index/

能够将 Cookie 保存到文件中以供之后使用：

curl -I http://127.0.0.1:5000/index/ --cookie-jar mycookies

在 stdout 上显示 cookie:

curl -I http://127.0.0.1:5000/index/ --cookie-jar -

请注意，没有HttpOnly属性的cookie，在浏览器中可使用document.cookie上访问，若是设置了 HttpOnly 属性，document.cookie就读取不到。

Set-Cookie: myfirstcookie=somecookievalue; HttpOnly

如今，该cookie 仍将出如今 Storage 选项卡中，可是 document.cookie返回的是一个空字符串。

从如今开始，为方便起见，使用Flask的 response.set_cookie() 在后端上建立 cookie。

我有一个 cookie，如今怎么办？

你的浏览器获得一个 cookie。如今怎么办呢?一旦有了 cookie，浏览器就能够将cookie发送回后端。

这有许多用途发如：用户跟踪、个性化，以及最重要的身份验证。

例如，一旦你登陆网站，后端就会给你一个cookie：

Set-Cookie: userid=sup3r4n0m-us3r-1d3nt1f13r

为了在每一个后续请求中正确识别咱们的身份，后端会检查来自请求中浏览器的 cookie

要发送Cookie，浏览器会在请求中附加一个Cookie标头：

Cookie: userid=sup3r4n0m-us3r-1d3nt1f13r

cookie 能够设置过时时间: Max-Age 和 expires

默认状况下，cookie 在用户关闭会话时即关闭浏览器时过时。要持久化cookie，咱们能够经过expires或Max-Age属性

Set-Cookie: myfirstcookie=somecookievalue; expires=Tue, 09 Jun 2020 15:46:52 GMT; Max-Age=1209600

注意：Max-Age优先于expires。

cookie的做用域是网站路径: path 属性

考虑该后端，该后端在访问http://127.0.0.1:5000/时为其前端设置了一个新的 cookie。相反，在其余两条路径上，咱们打印请求的cookie：

from flask import Flask, make_response, request

app = Flask(__name__)


@app.route("/", methods=["GET"])
def index():
    response = make_response("Here, take some cookie!")
    response.set_cookie(key="id", value="3db4adj3d", path="/about/")
    return response


@app.route("/about/", methods=["GET"])
def about():
    print(request.cookies)
    return "Hello world!"


@app.route("/contact/", methods=["GET"])
def contact():
    print(request.cookies)
    return "Hello world!"

运行该应用程序:

FLASK_ENV=development FLASK_APP=flask_app.py flask run

在另外一个终端中，若是咱们与根路由创建链接，则能够在Set-Cookie中看到cookie：

curl -I http://127.0.0.1:5000/ --cookie-jar cookies

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 23
Set-Cookie: id=3db4adj3d; Path=/about/
Server: Werkzeug/1.0.1 Python/3.8.3
Date: Wed, 27 May 2020 09:21:37 GMT

请注意，此时 cookie 具备Path属性：

Set-Cookie: id=3db4adj3d; Path=/about/

/about/ 路由并保存 cookit

curl -I http://127.0.0.1:5000/about/ --cookie cookies

在 Flask 应用程序的终端中运行以下命令，能够看到：

ImmutableMultiDict([('id', '3db4adj3d')])
127.0.0.1 - - [27/May/2020 11:27:55] "HEAD /about/ HTTP/1.1" 200 -

正如预期的那样，cookie 返回到后端。如今尝试访问 /contact/ 路由：

url -I http://127.0.0.1:5000/contact/ --cookie cookies

在 Flask 应用程序的终端中运行以下命令，能够看到：

ImmutableMultiDict([])
127.0.0.1 - - [27/May/2020 11:29:00] "HEAD /contact/ HTTP/1.1" 200 -

这说明啥?cookie 的做用域是Path 。具备给定路径属性的cookie不能被发送到另外一个不相关的路径，即便这两个路径位于同一域中。

这是cookie权限的第一层。

在cookie建立过程当中省略Path时，浏览器默认为/。

cookie 的做用域是域名: domain 属性

cookie 的 Domain 属性的值控制浏览器是否应该接受cookie以及cookie返回的位置。

让咱们看一些例子。

主机不匹配（错误的主机）

查看 https://serene-bastion-01422.herokuapp.com/get-wrong-domain-cookie/设置的cookie：

Set-Cookie: coookiename=wr0ng-d0m41n-c00k13; Domain=api.valentinog.com

这里的 cookie 来自serene-bastion-01422.herokuapp.com，可是Domain属性具备api.valentinog.com。

浏览器没有其余选择来拒绝这个 cookie。好比 Chrome 会给出一个警告(Firefox没有)

主机不匹配（子域名）

查看 https://serene-bastion-01422.herokuapp.com/get-wrong-subdomain-cookie/设置的cookie：

Set-Cookie: coookiename=wr0ng-subd0m41n-c00k13; Domain=secure-brushlands-44802.herokuapp.com

这里的 Cookie 来自serene-bastion-01422.herokuapp.com，但“Domain”属性是secure-brushlands-44802.herokuapp.com。

它们在相同的域上，可是子域名不一样。一样，浏览器也拒绝此cookie：

主机匹配（整个域）

查看 https://www.valentinog.com/get-domain-cookie.html设置的cookie：

set-cookie: cookiename=d0m41n-c00k13; Domain=valentinog.com

此cookie是使用 Nginx add_header在Web服务器上设置的：

add_header Set-Cookie "cookiename=d0m41n-c00k13; Domain=valentinog.com";

这里使用 Nginx 中设置cookie的多种方法。 Cookie 是由 Web 服务器或应用程序的代码设置的，对于浏览器来讲可有可无。

重要的是 cookie 来自哪一个域。

在此浏览器将愉快地接受cookie，由于Domain中的主机包括cookie所来自的主机。

换句话说，valentinog.com包括子域名www.valentinog.com。

同时，对valentinog.com的新请求,cookie 都会携带着，以及任何对valentinog.com子域名的请求。

这是一个附加了Cookie的 www 子域请求：

下面是对另外一个自动附加cookie的子域的请求

Cookies 和公共后缀列表

查看 https://serene-bastion-01422.herokuapp.com/get-domain-cookie/:设置的 cookie：

Set-Cookie: coookiename=d0m41n-c00k13; Domain=herokuapp.com

这里的 cookie 来自serene-bas-01422.herokuapp.com，Domain 属性是herokuapp.com。浏览器在这里应该作什么

你可能认为serene-base-01422.herokuapp.com包含在herokuapp.com域中，所以浏览器应该接受cookie。

相反，它拒绝 cookie，由于它来自公共后缀列表中包含的域。

Public Suffix List（公共后缀列表）。此列表列举了顶级域名和开放注册的域名。浏览器禁止此列表上的域名被子域名写入Cookie。

主机匹配（子域）

查看 https://serene-bastion-01422.herokuapp.com/get-subdomain-cookie/:设置的 cookie：

Set-Cookie: coookiename=subd0m41n-c00k13

当域在cookie建立期间被省略时，浏览器会默认在地址栏中显示原始主机，在这种状况下，个人代码会这样作:

response.set_cookie(key="coookiename", value="subd0m41n-c00k13")

当 Cookie 进入浏览器的 Cookie 存储区时，咱们看到已应用Domain ：

如今，咱们有来自serene-bastion-01422.herokuapp.com 的 cookie, 那 cookie 如今应该送到哪里?

若是你访问https://serene-bastion-01422.herokuapp.com/，则 cookie 随请求一块儿出现：

可是，若是访问herokuapp.com，则 cookie 不会随请求一块儿出现：

归纳地说，浏览器使用如下启发式规则来决定如何处理cookies(这里的发送者主机指的是你访问的实际网址):

若是“Domain”中的域或子域与访问的主机不匹配，则彻底拒绝 Cookie
若是 Domain 的值包含在公共后缀列表中，则拒绝 cookie
若是Domain 中的域或子域与访问在主机匹配，则接受 Cookie

一旦浏览器接受了cookie，而且即将发出请求，它就会说：

若是请求主机与我在Domain中看到的值彻底匹配，刚会回传 cookie
若是请求主机是与我在“Domain”中看到的值彻底匹配的子域，则将回传 cookie
若是请求主机是sub.example.dev之类的子域，包含在example.dev之类的 Domain 中，则将回传 cookie
若是请求主机是例如example.dev之类的主域，而 Domain 是sub.example.dev之类，则不会回传cookie。

Domain 和 Path 属性一直是 cookie 权限的第二层。

Cookies能够经过AJAX请求传递

Cookies 能够经过AJAX请求传播。 AJAX 请求是使用 JS （XMLHttpRequest或Fetch）进行的异步HTTP请求，用于获取数据并将其发送回后端。

考虑 Flask的另外一个示例，其中有一个模板，该模板又会加载 JS 文件：

from flask import Flask, make_response, render_template

app = Flask(__name__)


@app.route("/", methods=["GET"])
def index():
    return render_template("index.html")


@app.route("/get-cookie/", methods=["GET"])
def get_cookie():
    response = make_response("Here, take some cookie!")
    response.set_cookie(key="id", value="3db4adj3d")
    return response

如下是 templates/index.html 模板：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<button>FETCH</button>
</body>
<script src="{{ url_for('static', filename='index.js') }}"></script>
</html>

下面是 static/index.js 的内容：

const button = document.getElementsByTagName("button")[0];

button.addEventListener("click", function() {
  getACookie();
});

function getACookie() {
  fetch("/get-cookie/")
    .then(response => {
      // make sure to check response.ok in the real world!
      return response.text();
    })
    .then(text => console.log(text));
}

当访问http://127.0.0.1:5000/时，咱们会看到一个按钮。经过单击按钮，咱们向/get-cookie/发出获取请求并获取Cookie。正如预期的那样，cookie 落在浏览器的 Cookie storage中。

对 Flask 应用程序进行一些更改，多加一个路由：

from flask import Flask, make_response, request, render_template, jsonify

app = Flask(__name__)


@app.route("/", methods=["GET"])
def index():
    return render_template("index.html")


@app.route("/get-cookie/", methods=["GET"])
def get_cookie():
    response = make_response("Here, take some cookie!")
    response.set_cookie(key="id", value="3db4adj3d")
    return response


@app.route("/api/cities/", methods=["GET"])
def cities():
    if request.cookies["id"] == "3db4adj3d":
        cities = [{"name": "Rome", "id": 1}, {"name": "Siena", "id": 2}]
        return jsonify(cities)
    return jsonify(msg="Ops!")

另外，调整一下 JS 代码，用于下请求刚新增的路由：

const button = document.getElementsByTagName("button")[0];

button.addEventListener("click", function() {
  getACookie().then(() => getData());
});

function getACookie() {
  return fetch("/get-cookie/").then(response => {
    // make sure to check response.ok in the real world!
    return Promise.resolve("All good, fetch the data");
  });
}

function getData() {
  fetch("/api/cities/")
    .then(response => {
      // make sure to check response.ok in the real world!
      return response.json();
    })
    .then(json => console.log(json));

当访问http://127.0.0.1:5000/时，咱们会看到一个按钮。经过单击按钮，咱们向/get-cookie/发出获取请求以获取Cookie。 Cookie出现后，咱们就会对/api/cities/再次发出Fetch请求。

在浏览器的控制台中，能够看到请求回来的数据。另外，在开发者工具的Network选项卡中，能够看到一个名为Cookie的头，这是经过AJAX请求传给后端。

只要前端与后端在同一上下文中，在前端和后端之间来回交换cookie就能够正常工做：咱们说它们来自同一源。

这是由于默认状况下，Fetch 仅在请求到达触发请求的来源时才发送凭据，即 Cookie。

cookie 不能老是经过AJAX请求传递

考虑另外一种状况，在后端独立运行，能够这样启动应用程序:

FLASK_ENV=development FLASK_APP=flask_app.py flask run

如今，在 Flask 应用程序以外的其余文件夹中，建立index.html：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<button>FETCH</button>
</body>
<script src="index.js"></script>
</html>

使用如下代码在同一文件夹中建立一个名为index.js的 JS 文件：

button.addEventListener("click", function() {
  getACookie().then(() => getData());
});

function getACookie() {
  return fetch("http://localhost:5000/get-cookie/").then(response => {
    // make sure to check response.ok in the real world!
    return Promise.resolve("All good, fetch the data");
  });
}

function getData() {
  fetch("http://localhost:5000/api/cities/")
    .then(response => {
      // make sure to check response.ok in the real world!
      return response.json();
    })
    .then(json => console.log(json));
}

在同一文件夹中，从终端运行：

npx serve

此命令为您提供了要链接的本地地址/端口，例如http://localhost:42091/。访问页面并尝试在浏览器控制台打开的状况下单击按钮。在控制台中，能够看到：

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:5000/get-cookie/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)

由于 http://localhost:5000/ 与http://localhost:42091/.不一样。它们是不一样的域，所以会 CORS 的限制。

处理 CORS

CORS 是一个 W3C 标准，全称是“跨域资源共享”（Cross-origin resource sharing）。它容许浏览器向跨域的服务器，发出XMLHttpRequest请求，从而克服了 AJAX 只能同源使用的限制。

整个 CORS 通讯过程，都是浏览器自动完成，不须要用户参与。对于开发者来讲，CORS 通讯与普通的 AJAX 通讯没有差异，代码彻底同样。浏览器一旦发现 AJAX 请求跨域，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感知。所以，实现 CORS 通讯的关键是服务器。只要服务器实现了 CORS 接口，就能够跨域通讯。

默认状况下，除非服务器设置了Access-Control-Allow-Origin的特定HTTP标头，不然浏览器将阻止AJAX对非相同来源的远程资源的请求。

要解决此第一个错误，咱们须要为Flask配置CORS：

pip install flask-cors

而后将 CORS 应用于 Flask：

from flask import Flask, make_response, request, render_template, jsonify
from flask_cors import CORS

app = Flask(__name__)
CORS(app=app)


@app.route("/", methods=["GET"])
def index():
    return render_template("index.html")


@app.route("/get-cookie/", methods=["GET"])
def get_cookie():
    response = make_response("Here, take some cookie!")
    response.set_cookie(key="id", value="3db4adj3d")
    return response


@app.route("/api/cities/", methods=["GET"])
def cities():
    if request.cookies["id"] == "3db4adj3d":
        cities = [{"name": "Rome", "id": 1}, {"name": "Siena", "id": 2}]
        return jsonify(cities)
    return jsonify(msg="Ops!")

如今尝试在浏览器控制台打开的状况下再次单击按钮。在控制台中你应该看到

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:5000/api/cities/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)

尽管咱们犯了一样的错误，但此次的罪魁祸首是第二个路由。

你能够经过查看 “Network” 标签中的请求来确认,没有发送此类Cookie：

为了在不一样来源的Fetch请求中包含cookie，咱们必须提credentials 标志（默认状况下，它是相同来源）。

若是没有这个标志，Fetch 就会忽略 cookie，能够这样修复：

const button = document.getElementsByTagName("button")[0];

button.addEventListener("click", function() {
  getACookie().then(() => getData());
});

function getACookie() {
  return fetch("http://localhost:5000/get-cookie/", {
    credentials: "include"
  }).then(response => {
    // make sure to check response.ok in the real world!
    return Promise.resolve("All good, fetch the data");
  });
}

function getData() {
  fetch("http://localhost:5000/api/cities/", {
    credentials: "include"
  })
    .then(response => {
      // make sure to check response.ok in the real world!
      return response.json();
    })
    .then(json => console.log(json));
}

credentials: "include" 必须在第一个 Fetch 请求中出现，才能将Cookie保存在浏览器的Cookie storage 中：

fetch("http://localhost:5000/get-cookie/", {
    credentials: "include"
  })

它还必须在第二个请求时出现，以容许将cookie传输回后端

fetch("http://localhost:5000/api/cities/", {
    credentials: "include"
  })

再试一次，咱们还须要在后端修复另外一个错误：

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:5000/get-cookie/. (Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’).

为了容许在CORS请求中传输cookie，后端还须要设置 Access-Control-Allow-Credentials标头。

CORS(app=app, supports_credentials=True)

要点：为了使Cookie在不一样来源之间经过AJAX请求传递，能够这样作：

credentials: "include" 用于前端的 fetch 请求中
Access-Control-Allow-Credentials 和 Access-Control-Allow-Origin 用于后端

cookie能够经过AJAX请求传递，可是它们必须遵照咱们前面描述的域规则。

Cookie 的 Secure 属性

Secure 属性是说若是一个 cookie 被设置了Secure=true，那么这个cookie只能用https协议发送给服务器，用 http 协议是不发送的。换句话说，cookie 是在https的状况下建立的，并且他的Secure=true，那么以后你一直用https访问其余的页面（好比登陆以后点击其余子页面），cookie会被发送到服务器，你无需从新登陆就能够跳转到其余页面。可是若是这是你把url改为http协议访问其余页面，你就须要从新登陆了，由于这个cookie不能在http协议中发送。

能够这样设置 Secure 属性

response.set_cookie(key="id", value="3db4adj3d", secure=True)

若是要在真实环境中尝试，请能够运行如下命令，并注意curl在此处是不经过HTTP保存cookie：

curl -I http://serene-bastion-01422.herokuapp.com/get-secure-cookie/ --cookie-jar -

相反，经过HTTPS，cookie 出如今cookie jar中：

curl -I https://serene-bastion-01422.herokuapp.com/get-secure-cookie/ --cookie-jar -

cookie jar 文件：

serene-bastion-01422.herokuapp.com      FALSE   /       TRUE    0

不要被Secure欺骗：浏览器经过HTTPS接受cookie，可是一旦cookie进入浏览器，就没有任何保护。

由于带有 Secure 的 Cookie 通常也不用于传输敏感数据.

Cookie 的 HttpOnly 属性

若是cookie中设置了HttpOnly属性，那么经过js脚本将没法读取到cookie信息，这样能有效的防止XSS攻击，窃取cookie内容，这样就增长了cookie的安全性，即使是这样，也不要将重要信息存入cookie。

XSS 全称Cross SiteScript，跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，因此容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

若是有设置 HttpOnly 看起来是这样的：

Set-Cookie: "id=3db4adj3d; HttpOnly"

在 Flask 中

response.set_cookie(key="id", value="3db4adj3d", httponly=True)

这样，cookie 设置了HttpOnly属性，那么经过js脚本将没法读取到cookie信息。若是在控制台中进行检查，则document.cookie将返回一个空字符串。

什么时候使用HttpOnly？ cookie 应该始终是HttpOnly的，除非有特定的要求将它们暴露给运行时 JS。

可怕的 SameSite 属性

first-party cookie 和 third-party cookie

查看https://serene-bastion-01422.herokuapp.com/get-cookie/ 中所携带的 Cookie

Set-Cookie: simplecookiename=c00l-c00k13; Path=/

first-party是指你登陆或使用的网站所发行的 cookie，而third-party cookie 常为一些广告网站，有侵犯隐私以及安全隐患。

咱们将这类 Cookie 称为 first-party。也就是说，我在浏览器中访问该URL，而且若是我访问相同的URL或该站点的另外一个路径（假设Path为/），则浏览器会将cookie发送回该网站。

如今考虑在https://serene-bastion-01422.herokuapp.com/get-frog/上的另外一个网页。该页面设置了一个cookie，此外，它还从https://www.valentinog.com/cookie-frog.jpg托管的远程资源中加载图像。

该远程资源又会自行设置一个cookie:

咱们将这种 cookie 称为third-party(第三方) Cookie。

第三方 Cookie 除了用于 CSRF 攻击，还能够用于用户追踪。好比，Facebook 在第三方网站插入一张看不见的图片。

<img src="facebook.com" style="visibility:hidden;">

浏览器加载上面代码时，就会向 Facebook 发出带有 Cookie 的请求，从而 Facebook 就会知道你是谁，访问了什么网站。

使用 SameSite 属性

Cookie 的SameSite 属性用来限制third-party Cookie，从而减小安全风险。它能够设置三个值。

Strict
Lax
None

Strict最为严格，彻底禁止第三方 Cookie，跨站点时，任何状况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规则过于严格，可能形成很是很差的用户体验。好比，当前网页有一个 GitHub 连接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去老是未登录状态。

Lax规则稍稍放宽，大多数状况也是不发送第三方 Cookie，可是导航到目标网址的 Get 请求除外。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

导航到目标网址的 GET 请求，只包括三种状况：连接，预加载请求，GET 表单。详见下表。

设置了Strict或Lax之后，基本就杜绝了 CSRF 攻击。固然，前提是用户浏览器支持 SameSite 属性。

Chrome 计划将Lax变为默认设置。这时，网站能够选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能经过 HTTPS 协议发送），不然无效。

下面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Cookies 和认证

身份验证是 web 开发中最具挑战性的任务之一。关于这个主题彷佛有不少困惑，由于JWT中的基于令牌的身份验证彷佛要取代“旧的”、可靠的模式，如基于会话的身份验证。

来看看 cookie 在这里扮演什么角色。

基于会话的身份验证

身份验证是 cookie 最多见的用例之一。

当你访问一个请求身份验证的网站时，后端将经过凭据提交（例如经过表单）在后台发送一个Set-Cookie标头到前端。

型的会话 cookie 以下所示:

Set-Cookie: sessionid=sty1z3kz11mpqxjv648mqwlx4ginpt6c; expires=Tue, 09 Jun 2020 15:46:52 GMT; HttpOnly; Max-Age=1209600; Path=/; SameSite=Lax

这个Set-Cookie头中，服务器能够包括一个名为session、session id或相似的cookie。

这是浏览器能够清楚看到的惟一标识符。每当经过身份验证的用户向后端请求新页面时，浏览器就会发回会话cookie。

基于会话的身份验证是有状态的，由于后端必须跟踪每一个用户的会话。这些会话的存储多是：

数据库
像 Redis 这样的键/值存储
文件系统

在这三个会话存储中，Redis 之类应优先于数据库或文件系统。

请注意，基于会话的身份验证与浏览器的会话存储无关。

之因此称为基于会话的会话，是由于用于用户识别的相关数据存在于后端的会话存储中，这与浏览器的会话存储不一样。

什么时候使用基于会话的身份验证

只要能使用就使用它。基于会话的身份验证是一种最简单、安全、直接的网站身份验证形式。默认状况下，它能够在Django等全部流行的web框架上使用。

可是，它的状态特性也是它的主要缺点，特别是当网站是由负载均衡器提供服务时。在这种状况下，像粘贴会话，或者在集中的Redis存储上存储会话这样的技术会有所帮助。

关于 JWT 的说明

JWT是 JSON Web Tokens的缩写，是一种身份验证机制，近年来愈来愈流行。

JWT 很是适合单页和移动应用程序，但它带来了一系列新挑战。想要针对API进行身份验证的前端应用程序的典型流程以下：

前端将凭证发送到后端
后端检查凭证并发回令牌
前端在每一个后续请求上带上该令牌

这种方法带来的主要问题是：为了使用户保持登陆状态，我将该令牌存储在前端的哪一个地方？

对于前端开发来讲，最天然的事情是将令牌保存在localStorage中。因为许多缘由，这很糟糕。

localStorage很容易从 JS 代码访问，并且它很容易成为XSS攻击的目标。

为了解决此问题，大多数开发人员都将JWT令牌保存在cookie中，觉得HttpOnly和Secure能够保护cookie，至少能够免受XSS攻击。

将 SameSite 设置为 strict 就能够彻底保护 JWT免受CSRF攻击

设置为SameSite = Strict的新SameSite属性还将保护您的“熟化” JWT免受CSRF攻击。可是，因为SameSite = Strict不会在跨域请求上发送cookie，所以，这也彻底使JWT的用例无效。

那SameSite=Lax呢？此模式容许使用安全的HTTP方法（即GET，HEAD，OPTIONS和TRACE）将 cookie发送回去。 POST 请求不会以任何一种方式传输 cookie。

实际上，将JWT标记存储在cookie或localStorage中都不是好主意。

若是你确实要使用JWT而不是坚持使用基于会话的身份验证并扩展会话存储，则可能要使用带有刷新令牌的JWT来保持用户登陆。

总结

自1994年以来，HTTP cookie一直存在，它们无处不在。

Cookies是简单的文本字符串，但能够经过Domain和Path对其权限进行控制，具备Secure的Cookie，只能经过 HTTP S进行传输，而可使用 HttpOnly从 JS隐藏。

可是，对于全部预期的用途，cookie均可能使用户暴露于攻击和漏洞之中。

浏览器的供应商和Internet工程任务组（Internet Engineering Task Force）年复一年地致力于提升cookie的安全性，最近的一步是SameSite。

那么，什么才算是比较安全cookie？，以下几点：

仅使用 HTTPS
尽量带有 HttpOnly 属性
正确的SameSite配置
不携带敏感数据

人才们的 【三连】 就是小智不断分享的最大动力，若是本篇博客有任何错误和建议，欢迎人才们留言，最后，谢谢你们的观看。

代码部署后可能存在的BUG无法实时知道，过后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给你们推荐一个好用的BUG监控工具 Fundebug。

原文：https://gizmodo.com/the-compl...

交流

文章每周持续更新，能够微信搜索 【大迁世界】 第一时间阅读，回复 【福利】 有多份前端视频等着你，本文 GitHub https://github.com/qq449245884/xiaozhi 已经收录，欢迎Star。