JavaScript无法安全加密Cookie敏感数据，因前端代码可被用户查看篡改；应由后端生成、签名或加密，并通过HttpOnly+Secure+SameSite下发；前端仅传递不解析，避免明文存储敏感信息。
JavaScript 本身不适合、也不应承担 Cookie 敏感数据的“安全加密”任务。所谓“前端加密 Cookie”，本质上是一种幻觉——因为所有 JS 逻辑都运行在用户可控环境里，密钥、算法、流程全可被查看、调试、篡改或跳过。真正安全的做法是：敏感数据不进前端，加密签名全由后端完成，前端只做可信传递。
为什么 JS 加密 Cookie 不安全
攻击者只需打开开发者工具，就能：
- 直接读取
document.cookie（若未设HttpOnly） - 反编译混淆后的加密函数，还原密钥和逻辑
- 拦截请求，替换已加密值或重放旧 token
- 利用 XSS 注入脚本，绕过一切前端校验
正确做法：后端主导 + 前端配合
安全链条必须从前端“不碰敏感数据”开始：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
后端生成带签名/加密的凭证：如 JWT（HS256 或 RS256 签名）、AES-GCM 加密的 session_id，并通过
Set-Cookie下发，且必须包含：HttpOnly; Secure; SameSite=Strict（或Lax） -
前端绝不解析 Cookie 内容：不从
document.cookie里提取用户名、手机号、权限等字段；这些信息应在登录后，由后端验证 session 后，通过 HTTPS 响应体返回 -
若需前端写 Cookie（极少数中转场景）：仅限短期、低敏感 token，且严格限制属性：
path=/; Secure; SameSite=Lax; expires=...，绝不可设HttpOnly=false并存敏感值
替代方案：比 Cookie 更适合前端的存储方式
如果目标只是“让前端持有认证凭据”，推荐以下更可控的方式：
立即学习“Java免费学习笔记（深入）”；
- 内存变量（推荐 SPA）：将 access token 存在模块级变量或闭包中，页面刷新即丢失，天然防持久窃取
- IndexedDB + Web Crypto（谨慎使用）：对非关键标识符（如设备指纹片段）做轻量加密存储，需用户主动授权，且不用于主会话凭证
-
混合方案（最佳实践）：access token 存内存（短时效），refresh token 走
HttpOnly Cookie，由后端签发并校验
如果真要前端加一层编码（仅防初级窥探）
Base64 不是加密，只是编码，不能防恶意行为，但可避免明文暴露在开发者工具里：
- 用
js-cookie的withConverter自定义读写逻辑，集成CryptoJS或Web Crypto API - 注意：密钥不能硬编码在 JS 中；若用对称加密，密钥必须由后端动态下发（且需 TLS 保护）
- 实际效果有限——它防不住 XSS、防不住调试、防不住重放，仅适合非敏感状态标记（如语言偏好）
