Node.js应用默认不会主动下发安全响应头，攻击者可以借此实施跨站脚本注入或协议降级攻击。引入helmet中间件后，多个响应头可以被统一管理，其中内容安全策略（CSP）与HTTP严格传输安全（HSTS）需要结合业务资源来源进行细致配置，否则不是资源被浏览器拦截，就是策略因过于宽松而失去防护意义。下面先说明两者的作用边界，再给出可落地的配置方式。

理解CSP与HSTS的防护边界

内容安全策略由Content-Security-Policy响应头下发，浏览器根据指令列表判断页面中每个资源的加载是否合法。比如script-src控制脚本来源，style-src控制样式表，img-src控制图片，connect-src控制fetch或XMLHttpRequest请求目标。如果没有配置CSP，攻击者只要找到一处反射型XSS，就能注入任意脚本并读取同源数据。配置CSP后，即使恶意脚本被注入，浏览器也会因为来源不符合白名单而拒绝执行。

CSP指令之间还存在继承和回退关系。default-src是兜底策略，当某个具体指令未声明时，浏览器会使用default-src的值。这种机制虽然方便，但也容易造成误判：比如只写了default-src 'self'，却希望从CDN加载脚本，那么必须额外声明script-src，否则外链脚本会被阻止。理解这一点对后续编写策略非常重要。

HTTP严格传输安全（HSTS）通过Strict-Transport-Security响应头告知浏览器：在指定时间内，当前域名只能使用HTTPS访问。浏览器一旦收到该头，会自动把后续的HTTP请求在本地改写为HTTPS，从而阻止中间人发起的SSL剥离攻击。HSTS不能替代证书配置，但能弥补用户在地址栏输入http时可能暴露的窗口。

使用Helmet中间件快速配置安全头

helmet是Node.js生态中最常用的安全响应头中间件，内部整合了多个子模块。基础用法只需要在Express应用上调用app.use(helmet())，它会默认启用DNS预取控制、点击劫持防护、MIME嗅探防护，并移除X-Powered-By头。不过默认配置中CSP并没有强制启用，HSTS则使用了较短的有效期，因此生产环境必须自行覆盖。

如果要单独调整CSP与HSTS，可以给helmet传入配置对象。下面代码展示了自定义CSP指令列表以及HSTS参数的方式。

const express = require('express');
const helmet = require('helmet');
const app = express();
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", "https://cdn.ipipp.com"],
      styleSrc: ["'self'", "'unsafe-inline'"],
      imgSrc: ["'self'", "data:"],
      connectSrc: ["'self'", "https://api.ipipp.com"]
    }
  },
  strictTransportSecurity: {
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true
  }
}));
app.get('/', (req, res) => {
  res.send('安全响应头已生效');
});
app.listen(3000);

上述配置中，default-src限制默认资源只能来自同源，script-src允许同源脚本以及指定CDN域名，style-src额外允许内联样式。img-src放行data协议以支持base64图片，connect-src允许页面请求同源接口和指定的API域名。strictTransportSecurity的maxAge设为一年，includeSubDomains会同时保护子域，preload则在满足条件后可以申请加入浏览器预加载列表。注意这些配置需要和实际业务保持一致，不要直接照搬。

如果项目已经在别处通过反向代理或应用层设置了安全头，可以先用helmet({ contentSecurityPolicy: false, strictTransportSecurity: false })关闭相关子模块，避免响应头重复或被覆盖。CSP重复下发可能引起浏览器行为不一致，HSTS重复设置通常以后到者为准，但排查困难，所以保留一个配置入口比较稳妥。

编写CSP策略时的常见错误与调优

很多开发者在使用helmet配置CSP时，习惯为了快速解决报错而加入unsafe-inline和unsafe-eval，这实际上削弱了CSP对XSS的防护价值。unsafe-inline允许页面内的内联脚本执行，如果攻击者能够注入内联事件处理器，该策略就相当于放行。更安全的做法是使用nonce（一次性随机数）或hash，只允许特定脚本块执行。

下面给出一个动态nonce的配置示例。服务端每次请求生成随机字符串，写入模板时作为内联脚本的nonce属性，同时在CSP的script-src中动态拼接该值。

const crypto = require('crypto');
const express = require('express');
const helmet = require('helmet');
const app = express();
app.use((req, res, next) => {
  res.locals.cspNonce = crypto.randomBytes(16).toString('base64');
  next();
});
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: [
        "'self'",
        (req, res) => `'nonce-${res.locals.cspNonce}'`
      ],
      styleSrc: ["'self'", "'unsafe-inline'"]
    }
  }
}));
app.get('/', (req, res) => {
  const nonce = res.locals.cspNonce;
  res.send(`<script nonce="${nonce}">console.log('安全脚本');</script>`);
});

注意在该示例中，返回给前端的<script>标签必须带有对应的nonce属性，否则即使CSP策略中声明了nonce，浏览器也不会执行这段脚本。此外，同一个页面中如果既有内联脚本又有外链脚本，两者都需要满足script-src要求。某些旧浏览器对nonce的支持不完整，生产环境还需要做好降级测试。

CSP的调优阶段建议先开启报告模式，通过report-uri或report-to指令收集违规记录，在日志中观察哪些资源被误拦截，再逐步收紧策略。例如可以先配置default-src 'self'，外链资源被阻止时查看报告，把合法域名加入对应指令。这样既能及时发现问题，又不会因为策略过严导致线上功能异常。

HSTS的生效条件与部署风险

HSTS只在HTTPS响应中生效。如果用户的首次请求走HTTP，浏览器无法提前知道HSTS策略，必须等到收到HTTPS响应后才会记录。这种首访窗口是HSTS的固有盲区。为了进一步降低风险，可以在HTTP入口统一301跳转到HTTPS，并申请加入HSTS预加载列表。预加载列表由浏览器内置，一旦域名被收录，即使从未访问过该域名，浏览器也会直接使用HTTPS。

启用includeSubDomains前，需要确认所有子域都已经支持有效的HTTPS证书。如果某个子域仍然只提供HTTP服务，用户浏览器会在HSTS生效后强制访问HTTPS，导致该子域无法打开。maxAge设置也要谨慎：测试阶段可以从60秒开始，确认无异常后再提升到31536000秒。删除HSTS的唯一方式是等待maxAge到期，因此错误地设置很长有效期可能让故障无法快速恢复。

在Express中，helmet默认的HSTS maxAge为15552000秒，并且默认不启用includeSubDomains。生产环境一般会显式配置，如下所示。

app.use(helmet({
  strictTransportSecurity: {
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true
  }
}));

如果域名暂时不满足预加载条件，可以先把preload设为false，等HTTPS覆盖完整后再申请加入。部分代理或负载均衡设备会剥离响应头，需要确认HSTS头最终能够到达浏览器。某些环境下将Strict-Transport-Security手动写入HTTP响应是错误的做法，因为HSTS必须通过HTTPS传输才会被浏览器接受。

验证配置是否真正生效

修改完代码后，可以通过curl命令查看响应头。执行curl -I https://你的域名，观察输出中是否包含Content-Security-Policy和Strict-Transport-Security。如果使用了反向代理，还需要检查代理层是否透传这些响应头。

curl -I https://yourdomain.com

浏览器开发者工具的网络面板也能直接查看响应头。打开目标页面后，切换到网络标签，选中主文档请求，在响应头区域确认CSP和HSTS字段。如果使用了CSP报告模式，还需要关注报告收集接口是否收到违规数据。只有结合自动化测试和线上监控，才能保证安全头配置不会随着业务迭代而失效。

安全响应头并非设置一次就一劳永逸，每当引入新的第三方脚本、样式或接口域名时，都需要重新评估CSP策略是否覆盖。HSTS则可以配合证书续期和全站HTTPS改造形成完整的传输层防线。通过helmet的模块化配置，可以把这些细节集中管理，降低因手工拼接响应头带来的遗漏风险。