应由后端动态签发白名单并签名cookie，前端仅传递与校验；通过path、domain、samesite限制作用域；前端写cookie须校验referrer/origin是否在白名单内；cookie与localstorage白名单需语义一致并同步更新。
Cookie 本身不验证“谁写的”，只认请求路径、域名和协议。要限制写入来源，不能靠前端 JS 单方面控制，必须服务端主导、前后端协同，把白名单策略嵌入 Cookie 的生成与校验链路中。
白名单必须由后端动态签发，前端只负责传递与校验
前端 JavaScript 不应自行构造敏感 Cookie（如 session、auth_token）。所有需写入的 Cookie 应由可信后端接口返回，并附带签名或哈希：
- 后端在下发 Cookie 前，根据当前请求的 Referer、Origin、User-Agent 及 IP 归属等维度，判断是否匹配预设白名单（如允许的调用方域名列表、合法跳转路径）
- 若匹配，才签发 Cookie 并在响应头中携带 Set-Cookie；同时可附加 X-Whitelist-Hash 或 Signature 头，供前端二次核验
- 前端收到响应后，可用公钥或共享密钥验证签名，失败则丢弃该 Cookie，不执行后续逻辑
用 Path + Domain + SameSite 缩小 Cookie 的作用边界
即使 Cookie 被签发，也要通过属性强制限定其生效范围，防止被误用或越权携带：
- Path=/api：确保该 Cookie 仅在 /api 及其子路径下随请求自动发送，不污染 /admin 或 /public
- Domain=.trusted-app.com（注意前导点号）：允许主域及所有子域共享，但禁止被 example.com 等无关域名读取或覆盖
- SameSite=Strict 或 Lax：阻止跨站请求携带 Cookie，大幅降低 CSRF 风险；若需跨域提交（如 OAuth 回调），则设为 SameSite=None; Secure，且必须搭配 HTTPS
前端 JS 写 Cookie 时主动校验当前上下文是否在白名单内
仅当业务确需前端写 Cookie（如主题偏好、语言设置），才启用此机制，并严格限制场景：
- 写入前检查 document.referrer 或 location.origin 是否属于白名单域名数组（如 ['https://app.trusted.com', 'https://dashboard.trusted.com']）
- 禁止在 iframe 中、或 referrer 为空/不可信时写入（如直接打开链接、恶意跳转）
- 写入时强制添加 HttpOnly=false（因需 JS 写）、Secure=true（仅 HTTPS）、Path=/（明确作用域），避免遗漏导致失效
配合 LocalStorage 白名单做运行时一致性校验
Cookie 和前端白名单应保持语义一致。例如，某功能模块只允许从特定域名加载脚本，那对应的功能开关 Cookie 也应与 LocalStorage 中缓存的白名单版本对齐：
- 从 localStorage 读出白名单对象（含 version、hash、domains 字段）
- 检查当前页面 origin 是否在 domains 列表中；若不在，即便 Cookie 存在，也视为无效，清空并重定向或降级
- 每次更新白名单（如后台推送新规则）时，同步刷新相关 Cookie 的有效期或值，避免旧策略残留
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
