JavaScript调用.NET Core API时Bearer Token防盗安全问题咨询

认知误区澄清 #

你提到的「JS发起API请求必须手动携带Token」是最常见的认知误区：

• 同域Web应用场景下，完全不需要JS接触Token，你可以选择把Token存在HttpOnly、Secure属性的Cookie中，这类Cookie无法被JS读取修改，浏览器会自动在同域请求中携带，完全不需要前端代码手动处理Token，从根源避免Token被前端脚本复制盗用的风险。
• 即便是前后端分离的跨域场景，只要服务端正确配置CORS规则允许携带凭证，同样可以用HttpOnly Cookie自动携带Token，不需要JS显式处理。
• 你在用的.NET Core原生支持同时配置Cookie认证和JWT头认证，可以根据业务场景灵活选择认证方式，前端Web调用时用Cookie模式即可。

Token被盗的核心风险场景 #

Token被盗的前提通常是以下两种情况：

• 把Token存储在localStorage、sessionStorage或者无HttpOnly属性的Cookie中，被XSS攻击脚本读取窃取
• 传输过程未走HTTPS，被中间节点抓包窃取明文Token

适配.NET Core + 前端Web场景的防护方案 #

• 优先选择HttpOnly Secure Cookie存储Token
  .NET Core可以直接配置Cookie认证中间件，示例代码如下：

  builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
      .AddCookie(options => 
      {
          options.Cookie.HttpOnly = true; // 禁止JS读取Cookie
          options.Cookie.SecurePolicy = CookieSecurePolicy.Always; // 仅HTTPS下传输
          options.Cookie.SameSite = SameSiteMode.Strict; // 禁止跨站携带，防范CSRF
          options.ExpireTimeSpan = TimeSpan.FromMinutes(30); // Token有效期
      });
  

  该模式下无需JS处理Token，自然不存在被前端脚本复制的风险。如果担心CSRF攻击，可以额外开启.NET Core自带的AntiForgery中间件做二次校验。

• 必须用JS显式携带Token的场景（比如多端共用一套API、需要把Token传给第三方集成等）

  • 不要把Token持久化在localStorage/sessionStorage中，改用JS内存变量存储，页面刷新后通过静默授权重新获取新Token，页面关闭后Token自动销毁，即使出现XSS攻击，可窃取Token的时间窗口也会被压缩到极短
  • 缩短Access Token的有效期到15~30分钟，配合Refresh Token机制续期，Refresh Token同样存在HttpOnly Cookie中，禁止JS接触
  • 配置严格的内容安全策略（CSP），禁止未授权的内联脚本、外部脚本执行，大幅降低XSS攻击成功率

• 通用增强措施

  • 全链路启用HTTPS，避免Token在传输过程中被抓包窃取
  • 服务端记录Token签发时的客户端指纹（如User-Agent哈希、IP段），如果请求携带的Token对应指纹和签发时差异过大，直接拒绝请求并作废该Token
  • 实现主动注销机制，用户退出登录时立刻作废当前Token和关联的Refresh Token

内容的提问来源于stack exchange，提问作者Old-fashioned-dev