必须为 Cookie 设置 Secure、HttpOnly 和 SameSite 属性。现代浏览器默认拦截未声明这些属性的 Cookie 写入，尤其是 HTTPS 页面下裸写 document.cookie 会被静默丢弃；后端 Set-Cookie 响应头缺一不可，前端仅可用 document.cookie 存非敏感偏好数据。
需要，而且必须做。不加防护的 Cookie 设置在今天几乎等同于主动暴露用户会话或行为数据。
为什么浏览器现在会拦截你的 document.cookie 写入？
现代浏览器（Chrome 120+、Firefox 115+、Safari 17+）默认对未声明安全属性的 Cookie 施加限制：如果页面是 https://，但你用 document.cookie = "sid=abc" 这种裸写法，它可能被静默丢弃，或仅在当前会话有效（即关闭标签页就消失）。
-
HttpOnly无法通过 JS 读取，但document.cookie只能设非HttpOnly的 Cookie；所以前端设的都默认可被 XSS 利用 -
Secure缺失时，http://页面能设、https://页面却可能拒绝读——不是报错，而是“查不到”，极难调试 -
SameSite默认值已从Lax升级为Strict（部分浏览器），跨站 POST 提交表单时若含认证Cookie，可能直接不携带
Set-Cookie 响应头里哪些字段不能省？
后端发 Set-Cookie 时，光写 session_id=xyz 是高危操作。以下三项现在属于事实上的必填项：
-
Secure：强制仅通过 HTTPS 传输，http://下设了也无效，且现代浏览器控制台会标黄警告 -
HttpOnly：阻止document.cookie和 JS 访问，防基础 XSS 窃取会话 -
SameSite=Strict或SameSite=Lax：前者防所有跨站请求携带，后者允许安全的 GET 跨站（如点击链接），推荐新项目起步用Strict，兼容老逻辑再降级
示例合法响应头：Set-Cookie: auth_token=abc123; Path=/; Secure; HttpOnly; SameSite=Strict; Max-Age=3600
立即学习“前端免费学习笔记（深入）”；
前端用 document.cookie 存用户偏好是否安全？
可以，但必须明确用途边界：只存非敏感、无状态、可丢失的数据，比如 theme=dark、language=zh-CN。一旦涉及登录态、权限标识、临时 token，就该交给后端发 HttpOnly + Secure 的 Set-Cookie 处理。
- 不要用
document.cookie存加密后的用户 ID——JS 可读即等于可解，攻击者开控制台就能 copy - 避免设置
expires过长（如 10 年），浏览器对长期 Cookie 的清理策略越来越激进，iOS Safari 尤其明显 - 如果必须存轻量身份信息（如匿名设备 ID），至少加上
path=/+domain=yourdomain.com限定作用域，防止子域污染
真正容易被忽略的点是：隐私合规不是“加个弹窗”就完事。GDPR 或国内《个人信息保护法》要求的是“目的限定”和“最小必要”，而很多团队把 Cookie 当成万能存储桶——存埋点 ID、存 AB 实验分组、存用户打字习惯……这些全挤在一个 SameSite=Lax 的 auth_token 里，既增加泄露面，也抬高合规审计风险。
