如何设置AJAX请求头中的token值进行身份验证？ajax请求头添加token

在前后端分离的架构中,Ajax请求携带Token是保障接口安全的核心环节，核心上文小编总结明确：最规范且安全的做法是在Ajax请求的headers中通过Authorization字段传递Bearer Token，同时必须配合后端CORS（跨域资源共享）配置及HTTP-only Cookie机制，以彻底杜绝XSS（跨站脚本攻击）窃取Token的风险。

标准实现方案：Authorization Header

在现代Web开发中,基于JWT（JSON Web Token）的身份验证已成为主流，前端在发起Ajax请求时，应将获取到的Token放入HTTP请求头中。

以原生JavaScript的fetch API为例，这是最推荐的实现方式，它语义清晰，且天然支持现代浏览器标准。

const token = localStorage.getItem('access_token'); // 获取存储的Token
fetch('/api/user/profile', {
    method: 'GET',
    headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}` // 核心：Bearer前缀不可省略
    }
})
.then(response => {
    if (response.status === 401) {
        // 处理Token过期或无效逻辑，如跳转登录页
        window.location.href = '/login';
        return;
    }
    return response.json();
})
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

若使用axios库，由于其封装特性，可通过interceptors（拦截器全局配置）统一处理，避免在每个请求中重复编写代码，极大提升代码可维护性。

axios.interceptors.request.use(config => {
    const token = localStorage.getItem('access_token');
    if (token) {
        config.headers.Authorization = `Bearer ${token}`;
    }
    return config;
}, error => {
    return Promise.reject(error);
});

关键点解析：

1. Bearer前缀：遵循RFC 6750标准，Authorization: Bearer 是业界通用规范，后端解析器通常依赖此前缀识别认证类型。
2. Content-Type：明确指定为application/json，确保后端正确解析请求体，避免因默认类型导致的解析错误。

安全架构深度解析：为何不建议直接放在URL或Body中？

许多初学者倾向于将Token放在URL参数或请求体中,这是严重的安全误区。

1. URL参数风险：URL会被浏览器历史记录、服务器日志、代理服务器日志明文记录，一旦Token泄露，攻击者可直接使用它访问所有受保护资源。
2. 请求体风险：GET请求通常没有请求体，且非幂等操作将Token放在Body中会增加后端解析复杂度，更重要的是，Body内容在传输过程中若未严格加密，同样存在被嗅探的风险。

相比之下,Header中的Authorization字段不会出现在URL日志中，且HTTP协议本身对Header的处理更为标准化和安全。

防御XSS攻击的最佳实践：HttpOnly Cookie

尽管Header方式灵活,但它面临一个致命弱点：JavaScript可以读取localStorage中的Token，如果网站存在XSS漏洞，攻击者可通过document.cookie或读取LocalStorage轻松窃取Token。

专业解决方案： 采用HttpOnly Cookie存储Token，设置Cookie时添加HttpOnly标志，使得JavaScript无法通过document.cookie访问该Cookie，从而从根源上阻断XSS窃取Token的可能。

Set-Cookie: token=eyJhbGciOiJIUzI1NiIs...; Path=/; HttpOnly; Secure; SameSite=Strict

• HttpOnly：禁止JS访问，防XSS。
• Secure：仅通过HTTPS传输，防中间人攻击。
• SameSite=Strict：严格限制跨站请求携带Cookie，防CSRF（跨站请求伪造）。

注意：若使用HttpOnly Cookie，Ajax请求会自动携带Cookie，无需手动在Header中设置Token，但需注意，此时需后端配合配置CORS，允许前端域名访问，并启用credentials: 'include'。

fetch('/api/user/profile', {
    method: 'GET',
    credentials: 'include' // 关键：允许携带Cookie
})

常见问题与排查指南

在实际开发中,请求头携带Token常遇到跨域或401错误，以下是快速排查思路：

1. 401 Unauthorized：检查Token是否过期，或前端传递的格式是否正确（是否遗漏Bearer前缀）。
2. CORS Preflight失败：若使用了自定义Header（如Authorization），浏览器会先发OPTIONS预检请求，确保后端允许Authorization头，并正确响应Access-Control-Allow-Headers。
3. Token丢失：检查localStorage是否被清除，或Cookie是否因SameSite策略被浏览器拦截。

相关问答

Q1: Ajax请求中，使用Authorization Header和HttpOnly Cookie各有何优劣？

A:

• Authorization Header：优势在于前后端完全解耦，适合移动端App或纯前端SPA应用，Token管理灵活，便于多端共享，劣势是易受XSS攻击，需前端自行处理Token刷新逻辑。
• HttpOnly Cookie：优势是安全性极高，天然防XSS窃取，且浏览器自动携带，无需前端手动管理，劣势是需额外处理CSRF攻击（通过SameSite或Token验证），且前后端域必须一致或配置好CORS，不适合跨域场景。

Q2: 如何优雅地处理Token过期并自动刷新？

A: 最佳实践是利用Axios拦截器，在response.interceptors中监听401状态码，当捕获到401时，暂停后续请求队列，调用刷新Token接口，若刷新成功，则用新Token重试所有挂起的请求；若刷新失败，则清除本地Token并跳转登录页，这种方式对用户透明，无需手动处理复杂的异步重试逻辑。

互动环节

在实际项目中,你更倾向于使用Header传递Token还是Cookie存储？在解决跨域认证问题时，你遇到过哪些棘手的坑？欢迎在评论区分享你的实战经验，我们将选取优质评论进行回复。