Fetch API请求未携带Cookie？Node.js服务端读取签名Cookie返回undefined

核心错误点 #

• 主机名不匹配导致Cookie不携带：登录流程中Cookie是基于localhost:5000域下发的，但后续Fetch请求指向的是127.0.0.1:5000，浏览器会将两个地址判定为完全独立的源，不会跨源携带对应域的Cookie，服务端自然读不到req.signedCookies.user值。
• 跨域Cookie配置缺失：跨端口请求属于跨域场景，当前代码没有配置跨域凭证允许的响应头，哪怕Fetch加了credentials: 'include'，浏览器也会拦截跨域请求携带的Cookie。
• Cookie属性配置不全：下发签名Cookie时没有配置必要的浏览器兼容属性，默认的Cookie同站策略设置和浏览器新版本的默认规则不匹配，会被拦截存不到本地。
• SQL查询传参格式错误：当前代码调用MySQL查询时，直接将邮箱字符串作为第二个参数传入，没有按照驱动要求将参数放在数组中传递，存在查询逻辑异常、SQL注入的风险。
• 接口响应格式不统一：未登录场景下接口返回纯文本提示，前端Fetch逻辑直接按JSON格式解析，会触发解析报错。

逐项修正方案 #

1. 统一前后端请求的主机名，移除主机名混用的情况，将Fetch请求的地址改为和登录域一致的http://localhost:5000/getCustomerInfo，避免浏览器跨源拦截Cookie。
2. 补全跨域响应头配置，将跨域逻辑放在所有路由注册之前：

   注意：Access-Control-Allow-Origin不能设置为通配符*，否则浏览器会直接拦截带凭证的跨域请求。

   app.use((req, res, next) => {
     res.header('Access-Control-Allow-Origin', 'http://localhost:3000');
     res.header('Access-Control-Allow-Credentials', true); // 允许跨域请求携带凭证/Cookie
     res.header('Access-Control-Allow-Headers', 'Content-Type');
     next();
   });
   

3. 补全下发Cookie的属性配置，替换原有简单的cookie设置逻辑：

   res.cookie('user', loginCredentials.Email, {
     signed: true,
     httpOnly: true, // 禁止前端JS读取Cookie，降低XSS攻击风险
     path: '/', // 明确Cookie对全站路径生效
     maxAge: 7 * 24 * 60 * 60 * 1000, // 设置7天有效期，避免会话结束Cookie就被清除
     sameSite: 'lax' // 同站开发场景下适配浏览器默认策略，生产跨域场景可改为'none'搭配secure配置
   });
   

4. 修正所有MySQL查询的传参格式，将占位符参数统一放在数组中传递：

   // 登录查询修正
   con.query("SELECT Password FROM Customers WHERE Email =?", [loginCredentials.Email], function(err, result) { /* 原有逻辑保持不变 */ })
   // 客户信息查询修正
   con.query("SELECT FirstName, LastName, Address, Email, Phone FROM Customers WHERE Email =?", [username], function(err, result) { /* 原有逻辑保持不变 */ })
   

5. 统一接口返回格式为JSON结构，避免前端解析报错：
   • 未登录场景返回res.json({ code: 401, msg: 'You are not logged in. Log in to place the order' })
   • 查询成功/失败场景均按JSON结构返回对应状态和数据。

长期优化建议 #

• 签名Cookie本质是防篡改不是加密，Cookie内容用户可解码查看，建议不要直接存储邮箱这类敏感信息，改为存储随机生成的会话ID，服务端侧通过会话ID关联用户信息，安全性更高。
• 密码哈希逻辑需确认使用bcrypt这类带随机盐的算法，避免使用MD5、SHA1这类弱哈希算法提升账号安全性。
• 接口逻辑增加异常兜底，数据库查询出错时要给前端返回明确的错误状态，不要只打日志不返回响应。
• 前端Fetch逻辑增加状态判断，先判断响应的内容类型再做解析，避免因为格式不一致触发未捕获的异常。

内容的提问来源于stack exchange，提问作者Mr. Engineer