技术问询：Auth-Token应存储在Cookie还是Header中？

Hey there, let's unpack the differences between using Headers and Cookies for auth token transfers, especially across different scenarios:

1. 可信系统间的REST调用 #

When you're dealing with communication between two trusted systems (like backend services talking to each other), using an HTTP Header is absolutely the cleaner, more straightforward option. You can simply attach the token via something like Authorization: Bearer <your-token>—no extra hoops with cookie attributes (domain, path, SameSite) to worry about. It's lightweight, easy to implement, and fits perfectly with REST's stateless paradigm.

2. Client-side JavaScript environments #

Things shift dramatically when we're talking about frontend JS code running in a browser:

• Cookies with HttpOnly flag: This is the far safer choice. Marking a cookie as HttpOnly tells the browser to restrict access to it from JavaScript entirely. That means even if an attacker manages to inject malicious scripts via XSS, they can't grab the auth token from the cookie. It's a critical defense layer against token theft.
• Auth Headers in JS: If you go this route, the auth token has to be accessible to your JavaScript code (since you need to manually set it in the request header). This puts the token directly in the reach of any running scripts—including malicious ones from XSS vulnerabilities. Even with best practices, this exposes you to a much higher risk of token theft compared to HttpOnly cookies.

The risky common practice #

It's true that some developers still use Auth Headers to send tokens from insecure client-side JS environments. This might be due to preferences in certain frontend architectures, or confusion around cross-origin cookie configurations. But make no mistake: unless you've implemented extremely strict XSS protections (like CSP, input sanitization, and more), this approach introduces unnecessary security risks.

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