JavaScript无法设置Cookie的Secure和HttpOnly属性，二者必须由服务端在Set-Cookie响应头中声明；前端只能通过HTTPS跳转、SameSite配置等配合提升安全性。
JavaScript 本身不能真正为 Cookie 配置 Secure 或 HttpOnly 属性。这两个属性必须由服务端在 HTTP 响应头中通过 Set-Cookie 字段声明，浏览器才认可并执行其安全约束。
Secure 属性不是前端能开启的开关
Secure 是一个传输约束标记，仅当服务端响应中包含 Set-Cookie: key=value; Secure 时，浏览器才会确保该 Cookie 只随 HTTPS 请求发送。
你在 JS 中写：
document.cookie = "token=abc; Secure";
浏览器不会解析 Secure 这个字符串——它只是被当作 Cookie 值的一部分存下来，毫无安全效果。
- 在 HTTP 页面执行，该语句会被忽略；
- 在 HTTPS 页面执行，Cookie 能写入，但不带“仅 HTTPS 发送”行为；
-
localhost是例外（开发友好），但http://127.0.0.1不行，容易误判环境。
HttpOnly 属性完全不可由 JS 设置
HttpOnly 的设计目标就是切断前端脚本访问路径。只要服务端在 Set-Cookie 头里加上 HttpOnly，浏览器就会：
- 禁止
document.cookie读取该 Cookie； - 不允许 JS 创建、修改或删除它；
- 仍自动随同域请求发送给服务端（不影响登录态）。
任何类似document.cookie = "sid=123; HttpOnly"的写法，都只是把HttpOnly当作普通字符串写入，不会触发保护机制。
前端能做的实际配合事项
虽然不能设置这两个属性，但前端可以主动降低风险：
- 所有跳转链接、资源加载（如
<script></script>、fetch）统一使用 HTTPS 协议，避免混合内容警告； - 跨域场景（如嵌入支付 SDK）中，确认后端已配
SameSite=None; Secure（Chrome 80+ 要求二者必须共存）； - 开发调试时可用
http://localhost，但上线前务必确保服务端开启Secure和HttpOnly； - 敏感凭证（如 session ID、access token）绝不通过 JS 显式写入 Cookie，优先交由后端下发。
真正生效的关键在服务端配置
- Node.js/Express：需识别反向代理（如 Nginx）传来的协议，常设
app.set('trust proxy', true)，并在响应中动态判断req.secure； - Nginx 反代：必须加
proxy_set_header X-Forwarded-Proto $scheme;，否则后端无法正确判断是否 HTTPS； - Django、Spring Boot 等框架均有对应配置项，例如 Spring 的
CookieSameSiteAttributeProvider或HttpServletResponse.addCookie()设置setHttpOnly(true)； - 全站启用 HTTPS + HSTS 头，可进一步防止协议降级攻击。
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
