NodeJS/Express JS API路由防护中JWT、CORS的漏洞及解决方案咨询

首先先明确两个常见的认知误区：

• 第一，JWT被抓包窃取的前提是未启用HTTPS传输。HTTP环境下所有请求头、请求体都是明文传输，别说JWT，账号密码都能被第三方直接捕获，这不是JWT本身的设计缺陷，是传输层安全不到位导致的。所有生产环境的API必须强制开启HTTPS，传输层加密之后第三方抓包只能拿到加密后的密文，根本解析不出JWT内容。
• 第二，CORS本身是浏览器专属的同源安全策略，它的作用只是限制浏览器跨域发起的请求，从来就不是用来限制cURL、Postman这类非浏览器客户端的，指望CORS拦截非浏览器请求属于对特性的误用。

1. 传输层安全加固（生产环境必做） #

• 全站点强制HTTPS，配置TLS 1.2及以上版本，禁用老旧不安全的加密套件，同时配置HSTS响应头，防止用户被跳转到HTTP站点。
• JWT统一放在Authorization: Bearer <token>请求头中传输，不要放在URL参数里，避免URL被日志、代理服务器等意外记录泄露。
• 不要在JWT的payload中存储密码、身份证号这类敏感信息，JWT的签名仅用来防篡改，本身是明文编码的，只要拿到就能通过base64解码内容。
• 给JWT设置合理的过期时间，敏感场景过期时间控制在15~30分钟，配合刷新令牌（Refresh Token）实现无感续期，就算令牌真的意外泄露，较短的有效时间也能大幅降低危害。

2. 令牌冒用额外校验手段 #

• 敏感操作（比如支付、修改账号核心信息）除了JWT校验之外，额外增加二次验证，比如短信验证码、动态口令、支付密码校验。
• 服务端可以将JWT和用户的UA、IP段进行绑定校验，如果JWT对应的请求UA或者IP和签发时的信息差异过大，直接要求用户重新登录。如果是移动网络用户IP经常变动的场景，可以放宽IP校验的粒度，比如只校验IP前两段，或者仅依赖UA+设备特征校验。
• 可配置令牌黑名单，用户主动登出、修改密码之后，将对应的未过期JWT加入黑名单，后续收到该令牌直接拒绝访问。黑名单可以用Redis这类内存数据库实现，过期时间和JWT本身的过期时间对齐即可，不会占用太多存储资源。

3. 抵御恶意批量请求的通用方案 #

• 接口限流：根据用户ID、IP对接口请求频率进行限制，比如普通用户1分钟最多请求10次接口，超过阈值直接返回429状态码拒绝访问，避免垃圾请求打垮服务。
• 人机验证：高频请求、异常请求场景下插入CAPTCHA验证，拦截自动化脚本的批量请求。
• 行为特征校验：服务端收集用户的正常操作行为特征，比如请求间隔、操作路径规律，识别异常行为的请求直接拦截。

4. 高敏感场景可选方案 #

如果是安全性要求极高的场景，可以放弃JWT这种无状态令牌，改用有状态的Session方案，所有会话信息存在服务端，用户侧只存一个Session ID，随时可以在服务端作废会话，管控力度更强。

内容的提问来源于stack exchange，提问作者Jarrett GXZ