如何让调用WordPress REST API的外部JS应用安全使用JWT？

Great question—this is a super common setup for integrating external apps with WP REST API, and while JWT already mitigates plaintext password exposure, there are still several security blind spots to watch out for. Let's break down the risks and actionable fixes to harden your implementation.

• XSS导致的令牌泄露：如果你的外部 JS/jQuery app 把 JWT 存在 localStorage 或 sessionStorage 里，任何成功的 XSS 攻击都能直接窃取令牌。因为这些存储机制对 JS 完全开放，恶意脚本可以轻松读取并发送到攻击者的服务器。
• MITM攻击（未启用HTTPS）：如果登录请求（获取JWT的步骤）或后续API请求走的是HTTP，攻击者可以在中间拦截明文传输的令牌、甚至初始的用户名密码，直接接管用户权限。
• 过长的令牌有效期+无刷新机制：如果你的JWT Access Token有效期设得太长（比如几小时甚至几天），一旦令牌被盗，攻击者可以长时间冒充用户操作。如果没有Refresh Token机制，用户登出后令牌依然有效直到过期，没法主动失效。
• 弱签名配置：很多WP JWT插件默认用HS256对称加密，如果你的签名密钥太简单（比如password123），攻击者可以暴力破解密钥，伪造合法的JWT。另外，极少数情况下配置错误会允许none算法（无签名），直接绕过验证。
• 缺失的声明验证：如果WP端没有严格验证JWT的核心声明（比如iss签发者、aud受众、exp过期时间），攻击者可以用其他系统签发的JWT来访问你的WP API，或者篡改过期时间延长令牌有效期。
• Refresh Token管理不当：如果Refresh Token存在不安全的存储（比如localStorage），或者没有绑定用户IP/设备，被盗后攻击者可以无限刷新获取新的Access Token。

针对上面的隐患，这里有具体的修复措施：

• 安全存储令牌：
  • 优先用HttpOnly、Secure、SameSite=Strict/Lax的Cookie存储JWT（尤其是Refresh Token）。HttpOnly标记能阻止JS读取Cookie，避免XSS窃取；Secure确保Cookie只在HTTPS下传输；SameSite能防范CSRF攻击。
  • 如果必须用localStorage（比如跨域场景），一定要严格做XSS防护：启用Content Security Policy (CSP)限制脚本来源，对所有用户输入做转义，避免DOM型XSS。
• 优化令牌生命周期：
  • 把Access Token的有效期设得很短，比如15-30分钟，限制攻击者滥用被盗令牌的窗口。
  • 实现Refresh Token机制：用有效期更长的Refresh Token（比如7天）来获取新的Access Token。Refresh Token必须存在HttpOnly Cookie里，且每次刷新后要生成新的Refresh Token，废弃旧的（滚动刷新）。
• 强化签名与密钥管理：
  • 改用RS256非对称加密算法：WP服务器用私钥签发JWT，外部应用用公钥验证（或者反过来，WP用公钥验证令牌）。这样即使公钥泄露，攻击者也没法伪造令牌。
  • 签名密钥要足够复杂：用至少32位的随机字符串，不要硬编码在代码里，存在WP的wp-config.php作为环境变量，定期轮换密钥。
• 严格验证JWT声明：
  • 在WP的JWT验证逻辑中，强制检查以下声明：
    • iss：必须匹配你的WP站点域名，确保令牌是你的系统签发的。
    • aud：必须匹配你的外部应用的唯一标识，防止令牌被其他应用滥用。
    • exp：必须验证令牌未过期，不要跳过这个检查。
    • 可选：nbf（生效时间）、iat（签发时间），防止提前使用或伪造的旧令牌。
• 强制HTTPS全链路：
  • 整个流程（登录获取令牌、API请求）必须走HTTPS，禁止HTTP访问。在WP后台配置HSTS头：Strict-Transport-Security: max-age=31536000; includeSubDomains，强制浏览器后续请求都用HTTPS。
• 添加额外安全层：
  • 启用WP的API请求频率限制，防止暴力破解令牌或滥用API。
  • 给登录接口添加双因素认证（2FA），即使用户名密码泄露，攻击者也没法获取JWT。
  • 实现令牌黑名单机制：用户登出、修改密码或权限变更时，将对应的Access Token和Refresh Token加入黑名单，WP验证时先检查黑名单。
• 定期审计与更新：
  • 定期更新WP核心、JWT插件和外部应用的依赖，修复已知漏洞。
  • 监控API请求日志，异常的请求（比如来自陌生IP的大量POST请求）要及时告警。

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