使用JWT保障API请求安全后，是否还需要对返回响应做安全处理？

多数场景下我们会使用JWT access token校验来保障发往API等服务的请求安全，但我们是否需要确保对应系统（或API）返回的响应足够安全？是否需要关注该问题，又该如何进行风险缓解？

API响应安全和请求侧的JWT校验同等重要，只做请求合法性校验完全不足以覆盖全链路的安全风险，响应侧的漏洞会直接导致数据泄露、业务逻辑被攻破等严重问题，必须重点关注。

• 敏感数据明文泄露
  风险点：哪怕用了HTTPS，响应中携带的未脱敏身份证、手机号、银行卡号、内部业务ID等信息，也可能因为前端日志打印、本地缓存、恶意浏览器插件窃取等场景泄露。
  缓解方式：遵守最小必要返回原则，不需要的字段坚决不要放到响应体中；必须返回的敏感字段统一做脱敏处理，例如手机号格式化为138****1234；前端不得明文存储响应中的敏感数据，存储时必须做对称加密。
• 响应内容被篡改
  风险点：极端场景下HTTPS也可能被降级绕过，或是前端本地缓存的响应被恶意程序篡改，会导致前端展示错误信息、提交错误业务请求，比如篡改余额字段后诱导用户转账。
  缓解方式：核心业务接口（比如支付、权限查询、个人核心信息查询）的响应增加签名校验，服务端用非对称加密私钥对响应核心字段生成签名，前端拿到响应后先验签，校验不通过直接丢弃响应拒绝处理；涉及核心状态变更的后续请求，服务端不得信任前端提交的从响应中获取的字段，必须二次查库校验。
• 错误信息过度泄露
  风险点：很多服务在报错时会直接将堆栈信息、SQL语句、内部服务地址、中间件版本号返回到响应中，攻击者可以通过这些信息快速定位系统漏洞，发起定向攻击。
  缓解方式：生产环境强制关闭详细错误栈输出，统一返回标准化错误码和模糊提示，例如将具体的SQL报错统一改为系统内部错误，请稍后重试，详细错误信息仅保留在服务端内部日志中。
• 跨站数据泄露（XS-Leaks）
  风险点：攻击者可以通过跨域请求的响应状态码、响应体积、加载耗时等特征，推断出响应中的敏感内容，比如判断当前登录用户是否有特定权限、是否购买过某类商品。
  缓解方式：敏感接口配置Cross-Origin-Resource-Policy响应头限制跨域访问；携带敏感数据的接口使用POST方法而非GET，避免被跨域简单请求获取；必要时可在响应中加入随机填充字节，避免攻击者通过响应体积推断内容。
• 缓存投毒风险
  风险点：如果CDN或用户浏览器缓存了被篡改的响应内容，所有访问对应资源的用户都会拿到恶意数据。
  缓解方式：包含用户私有数据的响应设置Cache-Control: private, no-store头，禁止公共CDN缓存；公共静态资源的响应添加内容哈希校验，避免被投毒后下发给用户。

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