Node.js后端项目的安全加固从来不是靠装几个中间件就能解决的事。很多团队在开发阶段把注意力全放在业务逻辑和接口性能上，等上线后被扫描工具报出一堆漏洞才回头补，结果往往是临时加过滤、硬编码绕过，反而把代码结构越改越乱。真正的安全加固应该从项目初始化阶段就嵌入到目录结构、依赖管理、请求处理、身份认证、日志记录这些基础环节里，而不是事后打补丁。

先看依赖管理。Node.js项目最大的风险面之一就是npm包。一个中等规模的后端项目通常会有几百到上千个传递依赖，其中任何一个包出现已知漏洞，都可能直接暴露你的服务。建议在项目根目录固定使用package-lock.json或npm-shrinkwrap.json锁定依赖版本，同时把npm audit集成到CI流程里。不要只在本地跑一次就完事，因为依赖树会随着时间变化。对于生产环境，可以设置npm config set audit-level high，让高等级漏洞直接阻断构建。另一个常被忽略的点是，很多开发者会顺手全局安装一些工具包，然后在项目里通过child_process调用，这种做法非常危险。全局包不受项目锁文件控制，版本漂移后可能引入不可预期的行为。所有运行期依赖必须显式声明在package.json里，并走项目内的node_modules路径。

环境变量和配置管理是第二个重灾区。硬编码数据库密码、JWT密钥、第三方API Key的代码在代码库里一搜一大把。即使后来改成了环境变量，很多人也习惯把.env文件提交到Git仓库，或者在Docker镜像构建时把敏感信息打进镜像层。正确的做法是：开发环境使用.env文件但必须加入.gitignore；生产环境通过容器编排平台或CI/CD系统的加密变量注入；所有敏感配置在应用启动时做一次完整性校验，缺少关键变量直接拒绝启动，而不是运行到一半才报错。另外，不要把整个配置对象打印到日志里，尤其是启动日志，很多开发者为了调试方便会输出全部环境变量，这等于把数据库连接串直接送到日志收集系统。

请求层的安全处理要从HTTP头、请求体大小、参数校验三个维度同时做。默认情况下，Express或Koa对请求体大小没有严格限制，攻击者可以发送超大JSON或表单数据拖垮服务。应该在中间件里设置合理的limit，比如express.json({ limit: '1mb' })，同时关闭扩展模式，避免嵌套对象导致的原型污染。对于查询参数和路径参数，必须做类型校验和范围限制。不要相信前端的任何校验，后端要独立做一遍。可以使用Joi、Zod或express-validator这类库，但要注意校验规则要覆盖所有对外暴露的接口，而不是只校验几个重要的。原型污染是Node.js特有的高风险问题，尤其是使用对象合并操作时，比如Object.assign或lodash的merge，攻击者可以通过构造__proto__字段篡改对象原型。修复方式是在合并前对键名做过滤，或者使用Object.create(null)创建无原型对象。

身份认证和会话管理是后端安全的核心。JWT虽然方便，但用错场景会带来严重问题。不要把JWT当作会话存储，不要在payload里放敏感信息，因为JWT的payload只是base64编码，任何人都能解码。JWT的密钥必须足够长且随机，至少256位，并且定期轮换。对于需要主动失效的场景，比如用户修改密码或管理员踢人，JWT本身做不到实时失效，必须配合Redis等存储维护一个黑名单或版本号。密码存储方面，绝对不要用MD5或SHA1，甚至SHA256加盐也不够，因为计算速度太快，容易被暴力破解。应该使用bcrypt、argon2或scrypt这类慢哈希算法，并设置合适的成本因子。登录接口要做速率限制，防止暴力破解，同时记录失败尝试，达到阈值后锁定账号或要求验证码。

数据库操作的安全加固重点在SQL注入和NoSQL注入。很多Node.js开发者以为用了ORM就万事大吉，其实ORM在某些场景下仍然会拼接原始SQL，比如sequelize.query或knex.raw。只要业务里有动态排序字段、动态表名或复杂查询，就很容易出现拼接漏洞。对于MongoDB，NoSQL注入同样存在，尤其是当接口直接接收JSON对象作为查询条件时，攻击者可以传入$gt、$ne等操作符绕过验证。修复方式是：对查询条件做白名单过滤，只允许特定字段和特定操作符；对排序字段和方向做枚举校验；所有原始SQL使用参数化查询，禁止字符串拼接。

文件上传和静态资源服务是另一个容易被突破的点。如果项目里允许用户上传文件，必须做三件事：限制文件类型，不能只靠扩展名判断，要检查文件头魔数；限制文件大小，并在磁盘上做配额管理；存储时重命名文件，不要使用用户提供的原始文件名，避免路径穿越。上传目录要放在Web根目录之外，通过专门的下载接口读取，而不是直接暴露静态路径。对于静态资源服务，要关闭目录列表功能，设置正确的Content-Type，并对敏感目录做访问控制。如果使用express.static，注意不要在生产环境开启dotfiles选项，否则可能暴露.git等隐藏文件。

日志和错误处理同样影响安全。很多生产事故的根源是错误堆栈直接返回给前端，里面包含数据库表结构、文件路径、依赖版本等敏感信息。应该统一错误处理中间件，对客户端只返回通用的错误码和消息，详细堆栈只记录在服务端日志里。日志内容要脱敏，尤其是请求体和响应体，避免记录密码、token、身份证号等敏感字段。同时，日志文件本身要设置合理的权限和轮转策略，防止磁盘被写满。对于关键操作，比如登录、权限变更、删除操作，要记录审计日志，包含操作者、时间、IP、操作对象和结果，方便事后追溯。

进程和基础设施层面的加固往往被应用开发者忽视。Node.js是单线程模型，一旦出现未捕获异常，整个进程就会崩溃。虽然可以使用process.on('uncaughtException')和process.on('unhandledRejection')兜底，但不要在里面继续执行业务逻辑，应该记录日志后优雅退出，让进程管理器重启。生产环境必须使用cluster模式或PM2等工具做多进程部署，并设置合理的重启策略。另外，Node.js运行时的安全选项也要配置，比如使用--frozen-intrinsics冻结内置对象，使用--disable-proto=delete禁用__proto__访问，这些选项可以显著降低原型污染和原型链攻击的风险。如果项目运行在容器里，要以非root用户启动，并设置只读文件系统，减少被攻破后的横向移动能力。

安全加固不是一次性工作，而是需要持续迭代的工程实践。建议在项目里建立安全基线检查清单，每次代码合并前自动执行依赖审计、静态代码扫描和敏感信息检测。对于已经上线的项目，可以定期做渗透测试和漏洞扫描，但不要完全依赖自动化工具，很多逻辑漏洞需要人工分析业务场景才能发现。安全投入的性价比最高的阶段是开发期，越往后修复成本越高。把上面这些点落实到代码规范和部署流程里，比出了事故再紧急修复要有效得多。