Secure属性必须由服务端在Set-Cookie响应头中声明，仅HTTPS下生效，前端JS无法设置；HTTP环境下浏览器直接丢弃该Cookie，且localhost等开发环境易误判失效。
Secure 属性只在 HTTPS 下生效，HTTP 环境下会直接丢弃 Cookie
Secure 不是前端能控制的开关，它由服务端在 Set-Cookie 响应头中声明，比如 Set-Cookie: sessionid=abc; Secure。浏览器收到后，仅当当前页面是 HTTPS 加载、且后续请求目标 URL 也是 HTTPS 时，才把该 Cookie 自动带上。
常见错误现象：
- 本地开发用
http://localhost:3000测试，但设置了Secure→ Cookie 根本不发送，登录态始终丢失 - 反向代理没透传 HTTPS 协议（如 Nginx 未设
proxy_set_header X-Forwarded-Proto https;）→ 后端误判为 HTTP，Secure被忽略或拒绝设置 - 混合内容：页面 HTTPS，但某处资源（如图片、iframe）走 HTTP → 该子资源发起的请求不会带
SecureCookie
判断是否生效最简单的方式：打开 DevTools → Application → Cookies，看对应条目右侧是否有 “Secure” 标签；再切到 Network，找任意请求的 Request Headers，确认 Cookie 字段里是否含该值。
HttpOnly 让 document.cookie 彻底看不到这条 Cookie
启用 HttpOnly 后，JavaScript 对该 Cookie 是“不可见”的——不是被拦截，而是压根不在 document.cookie 返回的字符串里出现。哪怕 XSS 成功注入脚本，document.cookie 也拿不到它。
立即学习“前端免费学习笔记（深入）”；
但要注意：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
HttpOnly不影响浏览器自动发送：AJAX、表单提交、页面跳转等所有请求仍会携带该 Cookie - 后端照样能读：
req.headers.cookie（Node.js）、$_COOKIE（PHP）完全不受影响 - 不能防 DOM XSS 或键盘记录等其他攻击面，只专防 Cookie 窃取
- 某些旧版容器（如 Servlet 2.5）默认不支持
HttpOnly，需手动加 Filter 注入响应头
Secure + HttpOnly 必须同时设，缺一不可
单独设 HttpOnly 而没设 Secure：XSS 无法读，但攻击者可在用户访问 HTTP 页面时抓包拿到明文 Cookie；单独设 Secure 而没设 HttpOnly：传输加密了，但 XSS 仍可执行 document.cookie 直接盗走值。
真正可用的安全组合至少包含三项：
-
HttpOnly: true—— 隔离 JS 访问 -
Secure: true—— 强制 HTTPS 传输 -
SameSite: Lax或Strict—— 防 CSRF 携带
例如 Express 中设置会话 Cookie：res.cookie('sessionid', 'xxx', { httpOnly: true, secure: true, sameSite: 'lax' })；PHP 中：setcookie('sessionid', 'xxx', ['httponly' => true, 'secure' => true, 'samesite' => 'Lax'])。
开发环境绕过 Secure 的临时方案有风险
本地调试时若无 HTTPS，有人会改成 secure: process.env.NODE_ENV === 'production'，这没问题；但更危险的是直接硬编码 secure: false 并上线——上线后 Secure 永远不会生效。
另一个易忽略点：Domain 属性若设得太宽（如 Domain=.example.com），子域名一旦存在 XSS 漏洞，可能被用来覆盖主站 Cookie；建议省略 Domain 或显式设为精确域名（如 Domain=api.example.com）。
真正起效的配置必须由后端输出 Set-Cookie 响应头，HTML 和 JavaScript 无法补救。任何试图用 document.cookie = "a=1; secure" 的写法，现代浏览器都会静默丢弃。
