Secure 和 HttpOnly 是 Set-Cookie 响应头中的服务端设置属性，前端 JavaScript 无法通过 document.cookie 设置或修改；Secure 强制 Cookie 仅 HTTPS 传输，HttpOnly 隔离 Cookie 免遭 JS 访问，二者需后端配合 TLS 和 SameSite 等共同生效。
Secure 和 HttpOnly 不是 HTML 属性，而是 Set-Cookie 响应头中由服务器设置的 Cookie 属性。浏览器在解析 Set-Cookie 时识别它们，HTML 本身无法通过 <script> 或标签直接控制这两个属性。
为什么 Secure 必须由后端设置，前端 JavaScript 无法开启
Secure 的作用是强制浏览器只在 HTTPS 连接中发送该 Cookie。这个判断发生在网络协议层，浏览器必须在构造 HTTP 请求前就决定“要不要带上这个 Cookie”——而这个决策依赖于当前页面是否通过 HTTPS 加载、目标请求 URL 是否为 HTTPS。JavaScript 没有权限干预这一底层行为。
- 即使你在 JS 中调用
document.cookie = "a=1; secure"，现代浏览器会静默忽略secure（或报错），因为这不是合法的客户端写入方式 - 只有服务端在响应头中发送
Set-Cookie: sessionid=abc; Secure，浏览器才会真正启用该限制 - 开发环境若无 HTTPS，
Secure会导致 Cookie 根本不被发送，登录态丢失——这是最常见的“本地测不通”原因
HttpOnly 如何实际阻断 document.cookie 读取
启用 HttpOnly 后，浏览器会从 JavaScript 的运行环境中彻底移除对该 Cookie 的可见性。这不是靠拦截 API 调用实现的，而是底层存储隔离。
-
document.cookie返回字符串中**完全不包含**带HttpOnly的条目，哪怕它真实存在且每次请求都在自动发送 -
XMLHttpRequest和fetch发起的请求仍会携带该 Cookie，但脚本无法读取响应头中的Set-Cookie（除非服务端额外暴露） - 服务端仍可通过
req.headers.cookie（Node.js）或$_COOKIE（PHP）正常读取——它只防“前端读”，不防“后端用”
Secure + HttpOnly 组合失效的典型场景
二者必须同时启用才有意义，但常见配置错误会让防护形同虚设：
立即学习“前端免费学习笔记（深入）”；
- 只设
HttpOnly但没开Secure：XSS 脚本虽读不到 Cookie，但攻击者可在用户访问 HTTP 页面时用抓包工具截获明文传输的 Cookie - 只设
Secure但没开HttpOnly：HTTPS 保证了传输安全，但 XSS 仍能通过document.cookie直接盗走值 - SameSite 缺失：即使前两者都对，CSRF 攻击仍可能利用用户已登录态发起跨站请求，建议至少配
SameSite=Lax - Cookie 的
Domain设得过宽（如Domain=.example.com）：子域名一旦有漏洞，可能被用来覆盖或窃取主站 Cookie
真正起效的配置必须由后端在 Set-Cookie 响应头中一次性发出，且需确认 TLS 已就绪、全站跳转 HTTPS 已部署。漏掉任一环节，安全链条就断了。
