JavaScript无法安全加密Cookie敏感数据，因前端代码可被用户查看篡改；应由后端生成、签名或加密，并通过HttpOnly+Secure+SameSite下发；前端仅传递不解析，避免明文存储敏感信息。
JavaScript 本身不能安全地加密 Cookie 中的敏感数据，因为所有前端代码都可被用户查看和篡改。真正安全的做法是：敏感数据根本不该由 JavaScript 设置或读取，而应交由后端生成、签名、加密，并通过 HttpOnly + Secure + SameSite 属性下发。若必须在前端参与（如 token 临时中转），需配合严格校验与最小化暴露。
为什么不能靠 JS 加密来保护 Cookie 敏感数据
浏览器中的 JavaScript 运行在用户可控环境里，任何加密逻辑（如 AES、RSA 或 base64+混淆）都能被反编译、调试、跳过或重放。攻击者可直接：
- 打开开发者工具 → 查看
document.cookie（若未设HttpOnly） - 拦截网络请求 → 获取明文 Cookie 字段
- 修改加密密钥或绕过校验逻辑
正确处理敏感数据的三步原则
1. 后端生成并加密，前端只传递不解析
登录成功后，服务端生成一个短期有效的、带签名（HMAC）或加密（AES-GCM）的 token（如 JWT），写入 Set-Cookie 响应头，且不暴露给 JS：
2. 前端仅用 Cookie 做身份凭证，不存敏感字段
比如不要把用户名、手机号、邮箱、权限列表等明文塞进 Cookie。这些信息应由后端在验证 session 后，按需返回 API 响应体中（且响应也需 HTTPS 传输）。
3. 若必须前端写 Cookie（如跨域 token 中转），务必限制作用域
参考安全写法（仅限可信上下文，如 iframe 消息通信）：
- 省略
domain，避免意外共享 - 显式设
Secure（强制 HTTPS） - 设
SameSite=Lax防 CSRF - 绝不设
HttpOnly=false且含敏感值
替代方案：比 Cookie 更适合前端存敏感态的方式
如果目标是“让前端持有某种认证凭据”，更合理的选择是：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 内存变量：将短期 token 存在闭包或模块级变量中，页面刷新即丢失（适合 SPA 单页应用）
- IndexedDB + Web Crypto：对非关键标识符做轻量加密存储（需用户主动授权，且不适用于会话主凭证）
- 服务端 Session + 短期 Refresh Token：前端只保管一个短时效 access token（存在内存），用 refresh token 向后端换新 token，refresh token 仍走 HttpOnly Cookie
如果硬要 JS 加密（不推荐，仅作兼容兜底）
仅限非敏感场景（如用户偏好哈希、防篡改标记），且必须满足：
立即学习“Java免费学习笔记（深入）”；
- 使用
encodeURIComponent()编码原始值，避免分号截断 - 密钥不写死在代码里（应由后端动态下发，且带时效）
- 搭配
expires和path严格限定生命周期与作用域 - 每次读取后立即验证签名（如拼接时间戳 + HMAC-SHA256），失败则丢弃
例如：document.cookie = "pref=" + btoa(sha256(userInput + salt + timestamp)) + "; expires=" + ...
