Cookie vs Authorization Header: Which Token Storage Method Is Safer?

1. Store token in a cookie

Frontend can avoid writing code by relying on the backend Set-Cookie header; the browser automatically includes the cookie on same‑origin requests.

Drawbacks

Cookies increase network traffic and bandwidth because CDNs often use a different domain to avoid sending cookies with static asset requests.

Security

Cookies can be marked HttpOnly to prevent JavaScript access and Secure to restrict transmission to HTTPS, mitigating XSS attacks. However, cookies are vulnerable to CSRF, and third‑party cookies are being phased out. SameSite can be set to reduce CSRF risk.

When the primary domain is shared, cookies can be shared across subdomains by setting Domain=example.com, which is not possible with the Authorization header.

Image requests such as <img/> also carry cookies, allowing fine‑grained access control for user‑specific images, but it adds bandwidth overhead for shared assets.

2. Store token in the Authorization header

JavaScript must add the token to the Authorization header, typically via a global request interceptor, which inherently protects against CSRF.

Node.js or other non‑browser environments cannot rely on cookies, so they use the Authorization header. The header lacks built‑in Secure or Expires attributes, but these can be implemented in code.

Frontend persistence usually uses LocalStorage, which is vulnerable to XSS theft and does not support cross‑origin sharing, even for subdomains.

Compliance

Many authentication standards (e.g., JWT) require the Authorization header for token transmission, especially when integrating third‑party services.

Reference: https://www.zhihu.com/question/558219586/answer/2710675882