Node.js cookie-parser安全指南：防御CSRF与XSS攻击的实战策略

1. 项目概述：为什么我们需要一份关于 cookie-parser 的安全指南？

如果你是一名 Node.js 开发者，尤其是使用 Express 框架的，那么cookie-parser这个中间件对你来说一定不陌生。它几乎是每个 Express 项目的标配，负责解析请求头中的 Cookie，并将其转换为一个易于操作的 JavaScript 对象，挂在req.cookies上。使用起来简单到只需要一行代码：app.use(cookieParser())。但正是这种“开箱即用”的便利性，让很多开发者，包括我自己在早期，都忽略了它背后潜藏的巨大安全风险。

我见过太多项目，在快速迭代业务功能时，对 Cookie 的处理停留在“能用就行”的阶段。直到某一天，用户数据泄露、账户被恶意操作，甚至服务器被攻击者利用发起大规模非法请求时，大家才回过头来排查，最终发现问题往往就出在 Cookie 这个看似不起眼的环节。Cookie 是 Web 应用维持用户状态的核心机制，它承载了会话标识、用户偏好、身份令牌等关键信息。一旦 Cookie 被攻击者窃取、篡改或滥用，就等于将自家大门的钥匙拱手让人。

这份指南的核心，就是围绕cookie-parser这个工具，深入剖析与之相关的两大经典 Web 攻击：CSRF（跨站请求伪造）和 XSS（跨站脚本攻击）。我们不仅要理解攻击是如何发生的，更要掌握一套从配置、编码到部署的完整防御策略。这不仅仅是理论，而是我踩过无数坑、处理过真实安全事件后，总结出的实战经验。无论你是正在构建一个新应用，还是维护一个已有系统，理解并实施这些防御措施，都是保障应用安全的必修课。

2. 核心安全威胁解析：CSRF 与 XSS 是如何利用 Cookie 的？

在深入防御细节之前，我们必须先搞清楚敌人是谁，以及他们是如何发动攻击的。很多开发者对 CSRF 和 XSS 的概念是模糊的，甚至混为一谈。实际上，它们的攻击原理、利用方式和防御侧重点都有显著不同，但 Cookie 往往是它们共同的目标或跳板。

2.1 CSRF：借刀杀人的“请求伪造”

CSRF 攻击的精髓在于“伪造”。攻击者并不需要窃取你的 Cookie 内容，他只需要诱骗你的浏览器，在你不知情的情况下，向一个你已认证过的网站发起一个恶意请求。因为浏览器会自动携带该网站下的 Cookie，服务器会认为这是一个合法的用户操作。

攻击场景还原：假设你登录了银行网站bank.com，服务器通过 Cookie 中的session_id来识别你的身份。此时，你不小心访问了一个恶意网站。这个网站的页面里隐藏了一个表单，其action指向bank.com/transfer，并预设了转账金额和收款账户。由于你已登录bank.com，浏览器在提交这个隐藏表单时，会自动带上bank.com的 Cookie。服务器收到带有合法session_id的转账请求，便会执行操作。整个过程，攻击者既不知道你的 Cookie 内容，也无法获取转账结果，但他成功地“借用”了你的身份和权限完成了攻击。

与 cookie-parser 的关联：cookie-parser在这里扮演的角色是“信息的提供者”。它忠实地将请求头中的 Cookie 解析出来，方便后续的中间件（如会话中间件）使用。如果应用没有对请求来源进行额外验证，那么cookie-parser解析出的“合法”Cookie，就成了 CSRF 攻击得以成功的“帮凶”。防御 CSRF 的关键，不在于保护 Cookie 不被读取（因为这是浏览器正常行为），而在于确保这个携带了 Cookie 的请求，确实是用户本人意愿发起的。

2.2 XSS：内部瓦解的“脚本注入”

与 CSRF 的“伪造请求”不同，XSS 攻击是向你的网站中“注入”并执行恶意脚本。一旦注入成功，攻击者就能在用户的浏览器环境中为所欲为，其中最常见的目的之一，就是窃取用户的 Cookie。

攻击类型细分：

1. 反射型 XSS：恶意脚本作为请求参数（如 URL 的查询字符串）的一部分发送给服务器，服务器未加处理直接将其“反射”回响应页面中执行。通常需要诱使用户点击一个精心构造的链接。
2. 存储型 XSS：恶意脚本被持久化保存到服务器数据库或文件里（例如论坛评论、用户昵称）。当其他用户浏览包含该内容的页面时，脚本自动执行，危害范围更广。
3. DOM 型 XSS：攻击发生在客户端，恶意脚本通过修改页面的 DOM 结构来执行，不经过服务器端处理。例如，前端 JavaScript 直接使用innerHTML或eval()处理了不可信的用户输入。

与 cookie-parser 的致命关联：这是最需要警惕的一点。如果网站存在 XSS 漏洞，攻击者注入的 JavaScript 代码可以轻松访问当前站点的 Cookie（除非设置了HttpOnly属性）。一句简单的document.cookie就能将用户的会话 Cookie 发送到攻击者控制的服务器。此时，cookie-parser本身并无过错，但漏洞的存在使得它解析出的 Cookie 价值连城，成为了攻击者的战利品。防御 XSS 的核心，是坚决杜绝不可信的脚本在页面中执行，并对敏感的 Cookie 施加额外的保护锁（HttpOnly）。

理解这两者的区别至关重要：CSRF 利用的是浏览器对 Cookie 的自动携带机制，攻击发生在“请求发起”环节；XSS 则是直接窃取或操纵 Cookie 本身，攻击发生在“脚本执行”环节。我们的防御体系也需要针对这两个不同的环节进行构建。

3. 构建纵深防御体系：从 cookie-parser 配置到应用层防护

知道了攻击原理，我们就可以有的放矢地构建防御工事。安全防御从来不是单一措施就能高枕无忧的，我们需要一个从 Cookie 本身到业务逻辑的纵深防御体系。

3.1 第一道防线：加固 Cookie 本身

在cookie-parser解析之前，我们应该首先确保服务器设置的 Cookie 是尽可能安全的。这主要通过设置 Cookie 的属性来实现。虽然cookie-parser主要用于解析请求中的 Cookie，但理解如何安全地设置 Cookie（通常通过res.cookie()）是整体防御的前提。

1. HttpOnly：隔绝 JavaScript 访问这是防御 XSS 窃取 Cookie 最有效、最应该默认开启的属性。设置HttpOnly=true后，该 Cookie 将无法通过客户端的document.cookieAPI 访问。

   res.cookie('sessionId', 'abc123', { httpOnly: true, // 关键！防止XSS窃取 secure: true, // 建议与secure同用 sameSite: 'Lax' });

   实操心得：对于任何用于身份认证的会话标识 Cookie，必须无条件设置HttpOnly。这并不会影响正常的 HTTP 请求携带，只会阻断恶意脚本的读取。

2. Secure：强制 HTTPS 传输设置Secure=true，浏览器只会在 HTTPS 请求中携带该 Cookie。这能有效防止在明文 HTTP 传输中被窃听。注意事项：在开发环境（localhost）或尚未部署 HTTPS 的生产环境中，设置此属性会导致 Cookie 无法正常工作，需根据环境动态配置。

3. SameSite：控制跨站携带这是一个对抗 CSRF 的利器。它可以限制 Cookie 在跨站请求中是否被发送。

   • SameSite=Strict：最严格，完全禁止跨站携带。用户从外站点击链接进入你的网站，首次请求也不会携带 Cookie，可能导致登录状态丢失，体验不友好。
   • SameSite=Lax（默认值）：宽松模式。允许从外站导航到本站的 GET 请求携带 Cookie（如点击链接），但禁止在跨站的 POST 提交、iframe 加载等场景携带。这在安全性和用户体验间取得了良好平衡。
   • SameSite=None：允许跨站携带，但必须同时设置Secure=true（即仅限 HTTPS）。

   res.cookie('sessionId', 'abc123', { httpOnly: true, secure: true, sameSite: 'Lax' // 现代浏览器默认值，有效缓解CSRF });

   为什么它能防 CSRF：一个典型的 CSRF 攻击请求是从攻击者站点（evil.com）发往目标站点（bank.com）的跨站请求。如果目标站点的关键 Cookie 设置了SameSite=Lax或Strict，浏览器将不会在这次跨站 POST 请求中自动携带该 Cookie，从而使服务器端的会话验证失败，攻击失效。

4. Domain 和 Path：限定作用范围明确指定domain和path，避免 Cookie 被发送到不必要的子域或路径，缩小攻击面。

3.2 第二道防线：实施 CSRF Token 验证

SameSite属性是重要的缓解措施，但并非万无一失（例如某些旧浏览器不支持，或需要处理SameSite=None的场景）。因此，对于执行重要操作（如转账、改密、发布内容）的请求，必须使用 CSRF Token。

原理：在用户会话中生成一个随机、不可预测的 Token（通常存储在服务器 session 或可签名的 Cookie 中）。在渲染表单或页面时，将此 Token 嵌入（如作为隐藏字段<input type="hidden" name="_csrf" value="token-value">）。当用户提交表单时，必须将这个 Token 一并提交。服务器在处理请求前，校验提交的 Token 与会话中存储的是否一致。因为攻击者无法预先知道或伪造这个 Token，所以无法构造出合法的请求。

在 Express 中的实现（以 csurf 中间件为例，注意：csurf 已弃用，此处为原理演示，推荐使用其他库如csurf的替代品或自行实现）：

const cookieParser = require('cookie-parser'); const session = require('express-session'); // 需要会话支持 const csrf = require('csurf'); // 警告：csurf 已不再维护 app.use(cookieParser()); app.use(session({ secret: 'your-secret' })); // 启用 csrf 保护 const csrfProtection = csrf({ cookie: true }); // 可配置基于cookie // 将 token 传递给视图 app.get('/form', csrfProtection, (req, res) => { res.render('send', { csrfToken: req.csrfToken() }); }); // 验证 POST 请求中的 token app.post('/process', csrfProtection, (req, res) => { // 如果 token 无效，csurf 中间件会自动抛出错误 res.send('数据已安全处理'); });

关键点：

• Token 的存储与关联：Token 必须与当前用户会话强关联。不能使用全局统一的 Token。
• Token 的保密性与随机性：使用密码学安全的随机数生成器（如 Node.js 的crypto.randomBytes）。
• Token 的提交方式：除了表单字段，也可以放在 HTTP 头（如X-CSRF-Token）中，适用于 AJAX 请求。
• 库的选择：由于csurf已弃用，可以考虑使用csrf-csrf、@fastify/csrf-protection（如果使用 Fastify）或按照其原理自行实现。核心逻辑就是“生成-下发-校验”。

3.3 第三道防线：彻底杜绝 XSS 漏洞

只要存在 XSS 漏洞，HttpOnly之外的 Cookie、用户隐私、页面内容都可能被窃取或篡改。防御 XSS 需要前后端共同努力。

1. 输入过滤与输出编码（后端责任）

   • 不要信任任何用户输入：对来自用户的所有数据（URL 参数、POST 数据、HTTP 头、甚至上传的文件名）进行严格的验证和过滤。建立白名单机制，只允许预期的字符和格式。
   • 上下文相关的输出编码：在将数据输出到 HTML、JavaScript、CSS、URL 等不同上下文时，必须使用相应的编码函数。
     • HTML 上下文：使用<,>,&等实体编码。模板引擎（如 EJS, Pug）通常默认提供编码，但需确认。对于富文本，使用严格的 HTML 净化库（如DOMPurify（客户端）或sanitize-html（服务端））。

     // 错误示例：直接拼接 res.send(`<div>用户输入: ${userInput}</div>`); // 正确示例：使用模板引擎（如EJS）自动编码 // 在视图模板中：<div>用户输入: <%= userInput %></div>

     • JavaScript 上下文：将数据放入 JavaScript 变量时，需进行 JSON 序列化（JSON.stringify）并注意引号。

     // 正确示例 const userData = <%- JSON.stringify(userData) %>;

     • URL 上下文：使用encodeURIComponent。

2. 避免不安全的 DOM 操作（前端责任）

   • 绝对避免使用innerHTML,outerHTML,document.write()直接插入未经验证的字符串。优先使用textContent或安全的 DOM API（如createElement,appendChild）。
   • 谨慎使用eval(),setTimeout(string),setInterval(string)以及new Function(string)，它们都会执行字符串形式的代码。
   • 使用现代前端框架（如 React, Vue, Angular），它们通常在设计上就提供了基础的 XSS 防护（如 React 默认转义插值）。

3. 内容安全策略（CSP）—— 最后的屏障CSP 是一个通过 HTTP 头Content-Security-Policy实施的强大安全层。它通过白名单机制，明确告诉浏览器哪些外部资源（脚本、样式、图片、字体等）可以加载和执行。

   // Express 中设置 CSP 头部（使用 helmet 中间件简化） const helmet = require('helmet'); app.use(helmet.contentSecurityPolicy({ directives: { defaultSrc: ["'self'"], // 默认只信任同源 scriptSrc: ["'self'", "trusted.cdn.com"], // 脚本只允许同源和指定CDN styleSrc: ["'self'", "'unsafe-inline'"], // 谨慎允许内联样式 imgSrc: ["'self'", "data:", "img.cdn.com"], // 禁止内联脚本执行，从根本上阻止大部分XSS // 但可能需要对旧代码进行重构 } }));

   CSP 的威力：即使攻击者成功注入了<script>alert('xss')</script>，如果 CSP 策略中script-src不包含'unsafe-inline'，浏览器也会拒绝执行这段内联脚本。这相当于给页面加了一把锁，钥匙（可信来源）掌握在你手里。

4. 实战配置与代码示例：打造安全的 Express 应用

理论说再多，不如一行代码。下面我将结合cookie-parser和其他中间件，展示一个具备基础安全防护的 Express 应用配置。

4.1 安全中间件栈配置

const express = require('express'); const cookieParser = require('cookie-parser'); const session = require('express-session'); const helmet = require('helmet'); // 安全头部集合 const { doubleCsrf } = require('csrf-csrf'); // csurf替代方案之一 const rateLimit = require('express-rate-limit'); // 限流，防暴力破解 const app = express(); // 1. 使用 Helmet 设置一系列安全 HTTP 头 app.use(helmet()); // 2. 配置 CSP (通过 Helmet)，严格限制资源来源 app.use( helmet.contentSecurityPolicy({ directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'"], // 禁止内联脚本和不信任的外部脚本 styleSrc: ["'self'", "'unsafe-inline'"], // 允许内联样式，必要时可收紧 imgSrc: ["'self'", "data:"], fontSrc: ["'self'"], connectSrc: ["'self'"], }, }) ); // 3. 解析 Cookie app.use(cookieParser(process.env.COOKIE_SECRET)); // 建议使用签名Cookie // 4. 初始化会话（用于存储 CSRF Token 等） const sessionConfig = { secret: process.env.SESSION_SECRET || 'a-very-strong-secret', resave: false, // 避免 session 被重复保存 saveUninitialized: false, // 不保存未初始化的 session cookie: { httpOnly: true, secure: process.env.NODE_ENV === 'production', // 生产环境启用 HTTPS sameSite: 'Lax', // 缓解 CSRF maxAge: 24 * 60 * 60 * 1000, // 1天 }, }; app.use(session(sessionConfig)); // 5. 配置 CSRF 保护 (使用 csrf-csrf 库) const { doubleCsrfProtection, generateToken } = doubleCsrf({ getSecret: (req) => req.session.csrfSecret || (req.session.csrfSecret = require('crypto').randomBytes(32).toString('hex')), cookieName: '__Host-psifi.x-csrf-token', // 建议使用 __Host- 前缀增强安全性 cookieOptions: { httpOnly: true, secure: process.env.NODE_ENV === 'production', sameSite: 'Lax', }, size: 64, // token 长度 }); // 为所有非安全方法（POST, PUT, DELETE, PATCH）启用 CSRF 保护 app.use((req, res, next) => { if (['POST', 'PUT', 'DELETE', 'PATCH'].includes(req.method)) { return doubleCsrfProtection(req, res, next); } next(); }); // 提供一个路由来获取 CSRF Token（例如用于前端表单或 AJAX） app.get('/api/csrf-token', (req, res) => { const csrfToken = generateToken(req); res.json({ csrfToken }); }); // 6. 全局请求体解析（注意顺序，需在 CSRF 之前） app.use(express.json()); app.use(express.urlencoded({ extended: true })); // 7. 应用级限流 const apiLimiter = rateLimit({ windowMs: 15 * 60 * 1000, // 15分钟 max: 100, // 每个IP限制100次请求 message: '请求过于频繁，请稍后再试。', standardHeaders: true, legacyHeaders: false, }); app.use('/api/', apiLimiter); // 对API路由应用限流 // --- 你的业务路由从这里开始 --- app.get('/', (req, res) => { // 在渲染页面时，需要将 CSRF Token 传递给模板 const csrfToken = generateToken(req); res.render('index', { csrfToken }); }); app.post('/submit-data', (req, res) => { // 由于启用了 CSRF 保护，无效的请求会被自动拒绝 // 请求头中需要包含 `X-CSRF-Token`，其值需与生成的 token 一致 res.send('数据提交成功！'); }); // 静态文件服务（放在最后） app.use(express.static('public')); const PORT = process.env.PORT || 3000; app.listen(PORT, () => { console.log(`安全的应用服务器运行在端口 ${PORT}`); });

4.2 前端如何配合 CSRF 保护

对于传统的表单提交，需要在表单中插入隐藏字段：

<form action="/submit-data" method="POST"> <input type="hidden" name="_csrf" value="<%= csrfToken %>"> <!-- 其他表单字段 --> <input type="text" name="data"> <button type="submit">提交</button> </form>

对于 AJAX 请求（如使用 Fetch API 或 Axios），需要将 Token 放在请求头中：

// 假设从 /api/csrf-token 获取了 token const csrfToken = 'your-csrf-token-value'; fetch('/api/submit', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': csrfToken // 关键：在请求头中携带 }, body: JSON.stringify({ data: 'some data' }) });

注意事项：确保你的前端 JavaScript 能够安全地获取到 CSRF Token。如果 Token 是通过 Cookie 设置的（doubleCsrf的默认方式之一），并且该 Cookie 是HttpOnly的，那么前端 JS 无法直接读取。此时，一种常见模式是服务器在渲染页面时，将 Token 值写入一个<meta>标签或内联的 JavaScript 变量中，供前端脚本使用。但要注意，如果页面存在 XSS 漏洞，这种方式获取的 Token 也会被盗用，因此必须首先确保没有 XSS。

5. 高级防护与监控策略

基础防御搭建好后，我们还需要一些进阶手段和监控措施，让安全体系更加稳固。

5.1 使用签名 Cookie 防止篡改

cookie-parser支持签名 Cookie。通过传入一个密钥（secret），中间件会对 Cookie 值进行签名。在解析时，它会验证签名是否有效，如果 Cookie 被客户端篡改，req.signedCookies对象中将不会包含该 Cookie，而req.cookies中会包含一个前缀为s:的无效值。

app.use(cookieParser('your-strong-secret-here')); app.get('/set-signed', (req, res) => { // 设置签名 Cookie res.cookie('mySignedCookie', 'sensitiveValue', { signed: true }); res.send('Cookie已设置（签名）'); }); app.get('/read-signed', (req, res) => { // 读取签名 Cookie const value = req.signedCookies.mySignedCookie; if (value) { res.send(`签名Cookie值（已验证）: ${value}`); } else { // 签名无效或Cookie不存在 res.send('Cookie无效或不存在'); } });

适用场景：适用于存储一些不希望被客户端随意修改，但又不需要绝对保密的数据（如用户ID、偏好设置标识）。注意：签名不等于加密，Cookie 值本身仍然是明文的，只是附带了防篡改的签名。

5.2 针对 JSON API 的 CSRF 防护考量

对于纯 JSON API，传统的基于表单 Token 的模式可能不适用。除了使用自定义请求头（如X-CSRF-Token）外，还可以考虑：

• 检查Content-Type头：真正的浏览器表单提交的Content-Type通常是application/x-www-form-urlencoded或multipart/form-data。而 AJAX 请求可以设置为application/json。可以在服务器端增加一层校验，拒绝非浏览器标准表单提交的敏感操作。但这并非绝对可靠，因为攻击者也可以伪造Content-Type。
• 使用自定义请求头：如前所述，这是最常用的方法。因为浏览器的同源策略会限制跨域请求中自定义请求头的发送（在发起预检请求时），这为简单请求（Simple Requests）提供了一层天然防护。但需注意，CORS 配置不当可能会削弱此防护。
• Origin/Referer 校验：对于关键操作，可以严格校验请求头中的Origin或Referer字段，确保请求来自预期的源。但需注意Referer头可能被某些浏览器隐私设置或代理过滤。

5.3 安全日志与监控

防御措施不是一劳永逸的，需要持续监控。

• 记录可疑请求：记录所有 CSRF 验证失败、包含可疑 XSS 载荷（如大量<script>标签）的请求。记录 IP、User-Agent、请求路径和载荷样本。
• 监控异常模式：使用日志分析工具监控短时间内大量相同操作的请求（可能为自动化 CSRF 攻击）、来自异常地理位置的登录等。
• 定期依赖扫描：使用npm audit或集成 Snyk、Dependabot 等工具，定期检查项目依赖（包括cookie-parser、express等）是否存在已知安全漏洞，并及时更新。

6. 常见问题排查与实战心得

在实际开发和运维中，你一定会遇到各种奇怪的问题。下面是我总结的一些常见坑点和排查思路。

6.1 CSRF Token 验证失败

• 症状：表单提交或 AJAX 请求返回 403，提示 CSRF Token 无效。
• 排查清单：
  1. Token 未正确传递：检查表单中隐藏字段的name和value是否正确，或 AJAX 请求头X-CSRF-Token是否设置。
  2. 会话问题：CSRF Token 通常与用户会话绑定。确认会话中间件（如express-session）已正确配置并生效。检查浏览器中是否有会话 Cookie。
  3. Token 过期/不匹配：确保生成 Token 和验证 Token 的是同一个会话。在单页应用（SPA）中，如果页面长时间打开，会话可能过期，需要重新获取 Token。
  4. 中间件顺序：确保cookie-parser和会话中间件在 CSRF 中间件之前使用。确保body-parser（或express.json()/express.urlencoded()）在 CSRF 中间件之前，这样 CSRF 中间件才能读取到请求体中的 Token。
  5. Cookie 作用域问题：如果 API 和前端处于不同子域，需要确保 CSRF Token Cookie 的domain和sameSite属性设置正确，以便跨域请求能携带。

6.2 HttpOnly Cookie 导致前端无法访问

• 症状：前端 JavaScript 无法通过document.cookie读取到某些 Cookie。
• 原因与解决：这是设计如此，是安全特性。如果前端确实需要访问某个值（如非敏感的配置标识），请将该值放在另一个未设置HttpOnly的 Cookie 中，或者通过安全的 API 接口返回。切勿为了前端方便而移除关键身份验证 Cookie 的HttpOnly属性。

6.3 SameSite 属性导致第三方登录/支付回调失败

• 症状：集成微信登录、支付宝支付等第三方服务时，回调请求无法携带会话 Cookie，导致用户状态丢失。
• 解决：对于特定的、已知的、可信的跨站 POST 请求回调端点，可以临时放宽策略。
  1. 精准配置：不要全局设置SameSite=None。只为该特定路由的响应 Cookie 进行设置。

  app.get('/auth/third-party/callback', (req, res) => { // ... 处理逻辑 res.cookie('sessionId', newSessionId, { httpOnly: true, secure: true, sameSite: 'None' // 仅为这个必要的回调放宽 }); res.redirect('/dashboard'); });

  2. 确保 Secure：设置SameSite=None时，必须同时设置Secure=true（即要求 HTTPS）。
  3. 考虑替代方案：将回调处理设计为无状态，通过一次性 Token 在 URL 中传递信息，回调后在服务端重新建立会话。

6.4 开发环境与生产环境的安全配置差异

• 问题：在本地开发使用 HTTP，但生产环境使用 HTTPS，导致Secure和SameSite=None的 Cookie 在本地不工作。
• 解决方案：使用环境变量进行动态配置。

  const isProduction = process.env.NODE_ENV === 'production'; app.use(session({ secret: 'your-secret', cookie: { httpOnly: true, secure: isProduction, // 生产环境才启用 Secure sameSite: isProduction ? 'Lax' : false, // 开发环境可设为false或Lax } }));

6.5 关于 cookie-parser 的“签名”与“加密”

这是一个常见的误解。cookie-parser的signed: true选项提供的是签名（Sign），而非加密（Encrypt）。

• 签名：在 Cookie 值后附加一个 MAC（消息认证码），用于验证数据在传输过程中是否被篡改。原始值仍然是明文。cookie-parser使用sha256HMAC 进行签名。
• 加密：将原始数据转换为密文，无法直接读取。Node.js 中可以使用crypto模块的createCipheriv/createDecipheriv进行加密解密。

如何选择：如果你需要防止用户篡改 Cookie 值（如用户ID），使用签名。如果你需要存储真正的秘密（如临时令牌），应该将其存储在服务器端（如 Session、数据库），只在 Cookie 中存放一个无意义的会话 ID。如果必须在 Cookie 中存储秘密，应自行加密后再存储。

安全是一个持续的过程，而非一次性的任务。围绕cookie-parser的配置只是 Web 应用安全大厦中的一块砖。它需要与输入验证、输出编码、会话管理、HTTPS 强制、依赖库更新等其他安全实践紧密结合。每次引入新的第三方库、每次添加新的 API 接口、每次变更身份验证逻辑时，都请在心里默念一遍：这对我的 Cookie 和安全策略有什么影响？养成这样的安全思维习惯，才是抵御不断演进的安全威胁最坚固的盾牌。