面向：任何在 Express（Node.js）上运营 API 或应用的人。这里不讲攻击步骤 —— 这是一份关于你要为极简框架自己添加的防御的实务参考：按优先级排序的清单、分领域的对策，以及自查。想看跨框架的全貌，请参阅 按框架分类的安全入口。
按优先级排序的加固清单
自上而下落实这张表。P0 是前提，P1 是最高频的事故源，P2 是持续的日常维护。
P0 ── 前提（先做这个）
响应头（helmet）+ 禁用 x-powered-by ／ npm 依赖 CVE 监控 ／ 密钥从环境变量读取、不暴露堆栈
P1 ── 最高频事故源
输入校验与注入防御 ／ 所有者范围的授权
P2 ── 日常维护
限流与大小上限 ／ 会话、Cookie、CSRF ／ SSRF
| 优先级 | 对策 | 具体做法（Express） |
|---|---|---|
| P0 | 安全响应头 | helmet 类：CSP/HSTS/X-Content-Type 等。禁用 x-powered-by |
| P0 | npm 依赖 CVE | 用 npm audit/osv-scanner 监控；按实际运行版本判定，快速打补丁 |
| P0 | 密钥与错误 | 密钥从环境变量读取。生产环境不暴露堆栈跟踪 |
| P1 | 输入校验 | 校验/净化输入（类型/范围/允许值）。body 大小上限 |
| P1 | 注入 | 对数据库查询做绑定。当心 NoSQL 运算符注入（$）。不要把输入传给 eval |
| P1 | 授权 | 认证 + 每条路由上的所有者范围授权。JWT：验证签名、固定 alg |
| P2 | 限流 | 给登录/API 加尝试/吞吐限制。遏制暴力破解、滥用、DoS |
| P2 | 会话/Cookie | secure/httpOnly/sameSite。CSRF（Cookie 会话）。生产环境会话存储 |
| P2 | SSRF | 服务端抓取用白名单限制目标 + 阻断内部 IP/元数据 |
1. 安全响应头与收敛暴露（P0）
Express **默认不设置安全响应头。**先把它们加上。
- 用 helmet 类中间件添加 CSP、HSTS、X-Content-Type-Options、frameguard 等。
- 禁用
x-powered-by，减少框架/版本的暴露。 - 用 安全响应头检测 检查自己的站点。
2. 依赖（npm）与供应链（P0）
- 用
npm audit或 osv-scanner 机器化监控依赖的 CVE，按实际运行版本判定并快速打补丁（→ 监控依赖 CVE）。 - Node 的依赖树庞大，还有供应链风险（typosquatting、
postinstall钩子）。在安装时审查，并控制依赖数量。 - 让 Node 保持在受支持的（LTS）版本，不要把 EOL 版本晾在那里。
3. 输入校验与注入（P1）
- 校验/净化所有输入（body、query、params、headers）。设置 body 大小上限遏制 DoS。
- SQL：用占位符绑定；绝不用字符串拼接构造查询（→ 什么是 SQL 注入）。
- NoSQL：当心通过对象类型输入产生的运算符注入（
$）（不要把原始对象传入查询）。 - 不要把外部输入传给
eval这类危险的求值。
4. 认证与授权（P1）
常见（危险）
- 没有授权 —— "登录了 = 就允许"
- 只依赖中间件的顺序/是否存在
- 原样信任客户端提供的 ID/标志位
- JWT 签名未验证 / 允许
alg:none
正确
- 认证之外，在每条路由上做所有者范围的授权
- 在贴近数据的地方校验（不依赖顺序）
- 在服务端重新校验（抵御 ID 替换）
- JWT 验证签名 + 固定 alg（拒绝
alg:none）
参见 什么是 IDOR · 什么是 JWT。你可以自己检查 JWT 的内容（JWT 解码器）。
5. 限流与滥用防护（P2）
- 对登录、API、密码重置施加尝试/吞吐限制，遏制暴力破解、滥用和 DoS。
- 给请求 body 和上传设置大小上限（防止大负载耗尽内存等资源）。
6. 会话与 Cookie（P2）
- 给会话 Cookie 设置
secure/httpOnly/sameSite。 - Cookie 会话的应用要加上 CSRF 保护（→ 什么是 CSRF）。
- 生产环境使用合适的会话存储（默认的内存存储不适合生产）。登录时重新生成会话。
7. SSRF 与服务端抓取（P2）
- 服务端抓取用户提供的 URL 时，应把目标限制为白名单，并在连接时阻断到达内部 IP／云元数据（→ 什么是 SSRF）。
8. 错误处理与生产配置（P0–P2）
- 使用集中式错误处理器，并不要对外暴露堆栈跟踪。
- 以
NODE_ENV=production运行。在代理后面时，正确设置trust proxy，避免误判协议和客户端 IP。 - 可靠地终结 TLS/HTTPS。
验证：你的 Express 真的加固了吗
做完不等于结束 —— 只有检查过才算完成。以下是针对你自己环境的防御性自查。
响应头与暴露
x-powered-by 已消失。错误不泄露内部信息
授权确实生效
依赖、限流、SSRF
npm audit/osv 干净、登录限流生效，且对外抓取无法到达内部 IP。本站观点：用极简框架时，防御要自己设计
Express 的魅力在于轻量与自由 —— 这也意味着防御要由你自己来设计。Rails 和 Laravel 默认守护的部分（响应头、CSRF、内置的授权支持），在 Express 上要你有意识地接入。重点在于自上而下落实上面的表格：设置响应头、校验输入、在公开端点写好授权、并监控依赖的 CVE。Node 尤其依赖数量庞大，所以是否及时更新依赖，很大程度上决定了是否会发生事故。请放下"框架会替我守好"的假设，把防御明确地加上去。
延伸阅读
- 入口：按框架分类的安全 · Next.js 安全（同为 Node）
- 实务：监控依赖 CVE · 漏洞应对实务手册
- 术语：什么是 IDOR · 什么是 SSRF · 什么是 JWT · 什么是 CSRF
- 工具：安全响应头检测 · JWT 解码器
来源与确认范围
以下原始资料支持上文的配置、影响范围或应对措施，链接于2026年10月23日确认。请核对资料中的版本和配置条件。清单优先级及经验是本站的整理，不代表全文重新核验或安全保证。