第 9 卷

• 场景描述：PWA（渐进式Web应用）等支持离线访问的应用，对离线存储的业务数据（如离线订

• 实现方式：使用Service Worker配合IndexedDB，对离线数据进行AES加密存储。

二、前端加密的核心限制（不可替代后端加密）

前端加密的安全性依赖于浏览器环境和客户端代码，存在诸多不可控因素，因此无法替代后端加密，仅能作为补充手段，核心限制如下：

1. 密钥易泄露

• 前端加密的密钥必须存储在前端代码中（如JS文件）或通过网络传输到前端，攻击者可通过查看源

代码、拦截网络请求等方式获取密钥。一旦密钥泄露，加密数据可被轻易解密。

• 示例：前端使用RSA加密密码，公钥存储在JS文件中，攻击者可直接获取公钥，无法保证加密的安

全性（仅能防止明文传输，无法防止密钥被获取后的解密尝试）。

1. 加密逻辑易被篡改

• 前端代码完全暴露在客户端，攻击者可通过修改JS代码篡改加密逻辑（如禁用加密、替换为明文传

输），后端无法识别。

• 示例：攻击者通过浏览器开发者工具修改登录页面的JS代码，绕过密码加密逻辑，直接提交明文密

码。

1. 浏览器环境不可控

• 前端加密依赖浏览器的加密API（如Web Crypto API），若浏览器存在安全漏洞，或用户使用被篡

改的浏览器（如植入恶意插件的浏览器），加密过程可能被监控或篡改，导致数据泄露。

1. 无法保证后端接收数据的安全性

• 前端加密仅能保证数据传输过程的安全性，无法保证后端接收数据后的数据存储、处理过程的安全

性（如后端数据库被攻击）。后端必须对接收的加密数据再次验证、解密，并进行后端加密存储。

1. 性能开销与兼容性问题

• 前端加密（尤其是非对称加密）需要消耗浏览器的CPU资源，可能影响页面性能（如复杂加密逻辑

导致页面卡顿）。

• 部分旧浏览器不支持现代加密API（如Web Crypto API），存在兼容性问题，需额外处理降级方

案。

三、前端加密的使用原则

• 前端加密仅作为「补充防护」，核心安全保障必须依赖后端加密（如HTTPS、后端参数验证、数据

• 敏感数据必须在后端再次加密存储，前端加密仅用于传输过程的临时保护。

• 避免在前端存储核心密钥，尽量通过HTTPS等安全渠道动态获取密钥，且密钥有效期不宜过长。
• 前端加密需配合后端签名验证，防止加密逻辑被篡改。

1. 如何在前端实现安全的认证和授权机制?

前端认证和授权是Web应用安全的核心环节，认证（Authentication）用于验证用户身份（如“你是谁”），授权（Authorization）用于控制用户可访问的资源（如“你能做什么”）。前端实现安全的

认证和授权，需结合后端接口、安全的令牌机制、权限控制逻辑，同时防范会话劫持、令牌泄露等安全风险。

一、核心认证机制：基于Token的认证（推荐，替代Session认证）

目前前端主流的认证方式是「基于Token的无状态认证」（如JWT、OAuth 2.0），替代传统的 Session认证，其核心优势是无状态、可扩展、支持跨域，具体实现流程如下：

1. 基于JWT（JSON Web Token）的认证流程

• JWT结构：由Header（头部，指定加密算法）、Payload（载荷，存储用户ID、角色等非敏感信

息）、Signature（签名，后端用密钥生成，防止篡改）三部分组成，通过Base64编码拼接而成。

• 实现步骤：

1. 用户登录：前端将用户名/密码通过HTTPS提交到后端登录接口（密码建议前端先简单加密，如

RSA，避免明文传输）。

1. 后端验证：后端验证用户名/密码正确后，生成JWT令牌（设置有效期，如2小时），返回给前

端。

1. 前端存储：前端将JWT令牌存储在localStorage/sessionStorage中（不建议存储在Cookie中，

避免CSRF攻击）。

1. 后续请求：前端在所有需要认证的AJAX请求头中携带JWT令牌（如Authorization: Bearer

<token>）。

1. 后端验证：后端接收请求后，验证JWT令牌的有效性（是否过期、签名是否正确），验证通过则

放行，返回数据；验证失败则返回401 Unauthorized（未授权）。

1. 令牌刷新：当JWT令牌快过期时，前端调用刷新令牌接口（携带旧令牌），后端生成新令牌返

回，前端更新存储的令牌。

1. 基于OAuth 2.0的第三方认证（适用于第三方登录）

• 场景：用户通过微信、QQ、GitHub等第三方平台登录当前应用，无需注册新账号。

• 实现步骤：

1. 换取令牌：前端将授权码提交到后端，后端通过授权码向第三方平台换取访问令牌（Access

Token）和刷新令牌（Refresh Token）。

1. 认证授权：后端通过访问令牌获取用户信息（如微信用户的openid、昵称），生成当前应用的

JWT令牌返回给前端，后续流程与JWT认证一致。

二、核心授权机制：前端权限控制

授权机制用于控制用户可访问的资源和可执行的操作，前端需根据用户的角色/权限信息，实现页面级、按钮级的权限控制，核心实现方式如下：

1. 权限信息存储与初始化

• 后端在用户登录成功后，返回用户的角色（如admin、user、guest）和权限列表（如view:user、

edit:user、delete:user）。

• 前端将权限信息存储在localStorage/sessionStorage中，同时存入Vuex/Redux等状态管理工具，

供全局使用。

1. 页面级权限控制（路由守卫）

• 实现方式：使用前端路由守卫（如Vue Router的router.beforeEach、React Router的

Navigate），在路由跳转前验证用户是否拥有该页面的访问权限，无权限则跳转到登录页或无权限提示页。

• 示例代码逻辑：

• 定义路由权限配置： const routes = [{ path: '/admin', component: Admin,

meta: { requiresAuth: true, role: 'admin' } }]。

• 路由守卫验证：跳转前检查用户是否登录（是否存在JWT令牌）、用户角色是否匹配路由要求的

角色，不满足则拦截跳转。

1. 按钮级权限控制（指令/组件封装）

• 实现方式：封装权限控制指令或组件，根据用户的权限列表，动态显示/隐藏按钮，或禁用按钮点击

事件。

• 示例：

• Vue中封装v-permission指令： <button v-permission="['edit:user']">编辑用户

</button>，指令内部判断用户权限列表是否包含edit:user，不包含则隐藏按钮。

• React中封装PermissionButton组件： <PermissionButton

permission="delete:user">删除用户</PermissionButton>，组件内部根据权限控制渲染。