Express.js后端请求认证方案咨询：防止非法请求调用

首先要明确核心原则：前端运行的任何代码都不可完全信任，所以依赖前端生成校验码的思路从根本上存在安全隐患——无论代码混淆得多么复杂，资深用户都能通过调试、逆向工程破解生成逻辑。以下是几种成熟可靠的方案：

1. 基于Token的身份认证（JWT 或 Session） #

这是Web应用最常用的认证方式，完全由后端主导校验逻辑：

• JWT（JSON Web Token）：用户登录成功后，后端用私有密钥生成包含用户身份信息、过期时间的JWT，返回给前端。前端后续所有请求都在Authorization请求头中携带Bearer <token>。后端收到请求后，用相同的密钥验证JWT的签名与有效期，确认身份合法性。
  • 优势：无需服务器存储会话信息，适合分布式部署；可以设置短有效期，配合刷新Token机制平衡安全性与用户体验。
  • 注意：必须使用HTTPS传输，防止Token被中间人劫持；密钥绝对不能泄露。
• Session认证：用户登录后，后端创建Session并存储在服务器/Redis中，同时返回Session ID给前端（通常存在HttpOnly、Secure属性的Cookie中）。前端每次请求自动携带Cookie，后端通过Session ID查询会话信息验证身份。
  • 优势：Session存储在后端，可随时失效会话；HttpOnly Cookie能有效防止XSS攻击窃取凭证。

2. 请求签名机制（强化Token的安全性） #

如果担心Token被窃取后滥用，可以叠加请求签名机制，进一步提升安全性：

1. 用户登录时，后端额外返回一个仅用于签名的密钥（与Token分离，建议存在HttpOnly Cookie中，避免前端JS直接读取）。
2. 前端每次请求时，使用该密钥对请求的关键要素（如请求路径、当前时间戳、请求体的哈希值）进行HMAC-SHA256加密，生成签名后放在自定义请求头（如X-Request-Signature）中。
3. 后端收到请求后，按照相同的规则重新计算签名，与前端传来的签名对比；同时校验时间戳，只接受5分钟内的请求，防止重放攻击。
   这种方式下，签名规则由后端控制，用户即便拿到密钥，也必须严格遵循规则才能生成有效签名，且密钥可定期更换进一步降低风险。

3. 辅助防御措施（增加攻击成本） #

配合上述核心方案，可添加以下辅助措施：

• CORS限制：在Express后端配置CORS，只允许你的React域名发起请求，挡住浏览器层面的跨域非法调用（注意：工具可绕过CORS，仅作为辅助）。
• 请求频率限制：使用express-rate-limit等中间件，对同一IP或用户单位时间内的请求次数进行限制，防止批量恶意调用。
• 请求头校验：验证Origin或Referer字段，虽然可伪造，但能过滤部分低级攻击。

关键提醒 #

永远不要把安全校验逻辑放在前端，所有的身份验证、请求合法性校验必须由后端完成。前端只负责传递后端发放的凭证，不参与校验规则的生成。

内容的提问来源于stack exchange，提问作者Riccardo Perego