众所周知，设置会话 cookie 的安全做法是使用Set-Cookie带有Secure和HttpOnly标志的标头。但是在 HTTP 响应（和请求）正文中发送 cookie 是否存在任何安全问题？例如，像这样：
HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 09:23:37 GMT
.........
.........
.........
sessioncookie=abcdefgh
如果我使用Set-cookieAND 设置 cookie 并在同一个 HTTP 响应中发送 HTTP 响应正文，那会以某种方式降低安全性吗？
您不能在响应正文中设置cookie（浏览器不会在那里查找 cookie），您的浏览器也不能在请求正文中显示 cookie（服务器不会在那里查找）。根据定义，Cookie 包含在 HTTP 标头中（请参阅RFC 6265）。
您当然可以在请求或响应正文中发送其他会话数据或令牌（例如，通常在正文中传递CSRF 令牌），但如果您这样做，它们就不是 cookie。这是否是一个好主意是一个不同的问题。
大多数数据在正文中都可以，毕竟这是用户可以看到的唯一部分，有时需要向用户显示敏感数据。
但是，有些数据在正文中是不正确的。例如，您希望使 XSS 攻击不可用的任何内容都不能在正文中，并且只能包含在Http-only cookie中，以便无法从DOM中读取。
话虽这么说，一些数据在体内更好！例如，您不想显示默认 IIS 日志的任何内容都应该放在正文中。任何您不希望包含在伪造请求（又名 CSRF）中的内容都应该包含在正文中，而不是作为 cookie。
在 cookie 和正文中都设置令牌不一定是安全问题。事实上，这正是Double Submit Cookie CSRF 缓解所需的模式。
另一方面，如果您只是在正文中传递会话 ID，并且它是HttpOnly cookie的副本，那么您只是取消了使用 HttpOnly 标志的任何好处，因为相同的值可以从 DOM 中读取。
此外，还有一些非常有趣的事情：如果站点从服务器端设置了一个 HttpOnly cookie，并且相同的 cookie 值通过页面正文传递并通过客户端脚本设置，那么您的浏览器最终会得到两个具有相同名称的 cookie！应该避免这种情况，因为没有 HTTP 规范说明在这种情况下应该显示哪个 cookie，并且浏览器的行为会有所不同。