JWT防抓包需五项配置：一、强制HTTPS加密传输；二、HttpOnly+Secure Cookie存储Token；三、短时效Access Token（15分钟）配Refresh Token机制；四、Redis实现Token黑名单吊销；五、客户端绑定（device_hash）与nonce防重放校验。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您的JWT Token在传输过程中被抓包截获，则攻击者可能利用该令牌冒充合法用户发起未授权请求。以下是针对已发生或潜在抓包泄露场景的多项防御性网络安全配置方法：
一、强制启用HTTPS传输加密
HTTPS通过TLS协议对HTTP通信全程加密，使抓包工具捕获的数据为密文，从根本上阻断明文Token窃取路径。未启用HTTPS时，任何中间网络节点（如公共WiFi、代理 服务器）均可直接读取Authorization头中的Bearer Token。
1、在Web服务器（Nginx/Apache）中配置有效的SSL证书，确保所有API端点仅响应HTTPS请求；
2、在应用层添加HSTS（HTTP Strict Transport Security）响应头，强制浏览器后续请求自动升级为HTTPS；
3、禁用HTTP明文端口（如80端口），或配置301重定向至HTTPS地址；
4、前端AJAX请求中避免硬编码HTTP协议，统一使用相对协议或环境变量控制协议前缀。
二、采用HttpOnly + Secure Cookie存储Token
将JWT Access Token存入具备HttpOnly和Secure属性的Cookie中，可同时防御XSS脚本窃取与非加密信道泄漏。HttpOnly阻止JavaScript访问Cookie内容，Secure确保Cookie仅通过HTTPS传输，双重隔离客户端脚本与不安全网络的风险。
1、后端签发Token时，调用setCookie方法并显式设置HttpOnly=true、Secure=true、SameSite=Strict（或Lax）；
2、移除前端localStorage/sessionStorage中存储Token的逻辑，禁止document.cookie或window.localStorage.setItem操作；
3、验证响应Set-Cookie头是否包含HttpOnly、Secure及SameSite字段；
4、在CSP（Content-Security-Policy）响应头中限制内联脚本与外部域资源加载，进一步压缩XSS利用面。
三、实施短时效Access Token + 刷新令牌机制
缩短Access Token有效期（如15分钟），大幅压缩攻击窗口期；配合长期有效的Refresh Token完成无感续期，既保障安全性又不牺牲用户体验。即使Access Token被截获，其可用时间极短，且无法单独用于刷新新Token——必须配合服务端校验的Refresh Token。
1、配置JWT签发时exp声明为900秒（15分钟），而非默认3600秒或更长；
2、登录成功后，后端生成一对Token：短期Access Token（含user_id、scope等）与长期Refresh Token（含jti唯一标识、iss、exp=7天）；
3、Refresh Token必须以HttpOnly+Secure Cookie方式下发，且不返回至前端JavaScript上下文；
4、/auth/refresh接口接收Refresh Token后，先校验其有效性、未被加入黑名单、且未被重复使用，再签发新Access Token。
四、部署Token黑名单（Revocation List）
针对已确认泄露的Token，需支持主动吊销能力。虽违背JWT“无状态”设计初衷，但可通过轻量级外部存储（如Redis）实现高效黑名单校验，在每次请求鉴权阶段拦截已被标记的Token。
1、定义Token指纹：对原始JWT字符串执行MD5或SHA-256哈希，取前16位作为fingerprint键；
2、当用户登出、检测到异常行为（如同一Token多IP并发）、或安全事件响应时，将该fingerprint写入Redis，TTL设为与Token原exp一致；
3、JWT校验中间件在verifySignature之后立即查询redis.exists("jwt:blacklist:"+fingerprint)；
4、若存在匹配项，则直接返回401 Unauthorized，不进入业务逻辑处理流程。
五、引入客户端绑定与请求唯一性校验
在Token payload中嵌入不可预测的客户端特征，并在每次请求中附加一次性随机数（nonce），服务端通过比对历史记录与签名一致性实现细粒度防重放与设备锁定，使截获的Token在非原始环境失效。
1、登录时，后端生成device_fingerprint（如User-Agent+IP前段+Canvas Hash组合哈希值），写入Token的device_hash自定义claim；
2、每个API请求头中携带X-Request-ID（由客户端生成UUIDv4）与X-Nonce（单次有效随机串）；
3、服务端解析Token后，校验device_hash是否与当前请求来源匹配；
4、使用Redis SETNX命令尝试存储"nonce:"+X-Nonce，若已存在则拒绝请求，TTL设为5分钟。
