17370845950

单页应用路由参数应避免明文暴露，推荐服务端签发一次性签名Token替代原始参数；次选对称加密+Base64（需密钥动态下发）或哈希校验（需动态盐值）；根本原则是敏感信息不入URL，改用Cookie、Header或API获取。

在单页应用（SPA）中，路由参数通常以明文形式出现在 URL 中（如 /user?id=123&token=abc），这存在敏感信息泄露、篡改和重放等安全风险。HTML5 本身不提供路由加密能力，但可通过前端编码 + 后端配合的方式实现参数的混淆、签名、加密或令牌化，让 URL 看似随机且不可逆推原始值。

使用对称加密 + Base64 编码（轻量级前端方案）

适用于非高敏场景（如用户 ID、页面类型），要求前后端共享密钥。前端用 AES 或 CryptoJS 对参数对象加密后 base64 编码，拼入路由；跳转后解密还原。

• 安装 crypto-js：npm install crypto-js
• 加密示例（Vue Router 路由守卫中）：
  
  this.$router.push(`/secure/${CryptoJS.AES.encrypt(JSON.stringify({id: 1001, tab: 'profile'}), 'my-secret-key').toString()}`)
• 解密示例（beforeRouteEnter 或 setup 中）：
  const decrypted = CryptoJS.AES.decrypt(to.params.encrypted, 'my-secret-key');
  const params = JSON.parse(decrypted.toString(CryptoJS.enc.Utf8));
• 注意：密钥不能硬编码在前端生产环境，应通过环境变量注入或由后端动态下发（如首次登录返回短期密钥）

服务端签发一次性 Token 替代原始参数

最推荐的安全实践。前端不直接暴露业务参数，而是向后端请求一个带签名、有时效、可绑定用户/设备的一次性 token，再将该 token 作为路由参数（如 /order?tk=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...）。

• 后端生成 JWT 或自定义签名 token（含 payload：{uid: 123, order_id: "ORD-789", exp: 1717023600}，签名密钥不外泄）
• 前端仅负责携带 token 跳转，不解析也不修改
• 路由组件加载时，调用接口校验 token 并获取真实参数（服务端验证签名 + 过期时间 + 黑名单）
• 优势：URL 完全无业务含义，防篡改、防重放、易审计、可快速作废

路由参数哈希校验（防篡改，不防泄露）

若只需防止参数被恶意修改（如 id=123 改为 id=999），可用“参数+盐值”生成签名附在 URL 后，服务端/前端双重校验。

• URL 示例：/product/123?_s=8a3f5b2e9c1d，其中 _s 是 HMAC-SHA256("123"+"my-salt") 的十六进制摘要
• 前端跳转前计算签名并附加；进入路由时重新计算比对，不一致则拒绝渲染或跳转登录页
• 适合内部管

  

  理后台等对保密性要求不高、但需保障参数完整性的场景
• 注意：盐值必须保密，不能写死在前端代码里；建议由后端接口返回动态 salt

避免在 URL 中传递敏感参数的根本原则

加密只是补救手段，最佳实践是从设计上规避。以下情况应改用其他方式：

• 用户身份凭证（token、session_id）→ 存入 HttpOnly Cookie 或内存变量，通过 Authorization Header 透传
• 订单详情、支付数据 → 先跳转空路由（如 /checkout），再由组件内发起受鉴权保护的 API 获取
• 搜索关键词、筛选条件 → 使用 history.state 或 Vuex/Pinia 持久化，配合 scrollRestoration 保持体验
• 需要分享的深层链接 → 后端生成短链并映射到加密参数，用户点击短链后服务端 302 跳转至真实路由

不复杂但容易忽略：加密路由参数不是为了“看起来安全”，而是为了降低攻击面、满足合规要求（如 GDPR、等保）、建立纵深防御。真正关键的是明确参数用途、分级敏感度，并让前端与后端协同控制流转边界。