Node.js Web安全实战示例代码合集-node.js-CSS教程网

本文还有配套的精品资源，点击获取

简介：在Node.js开发Web应用时，安全防护至关重要。本示例代码全面展示如何在Node.js环境中实施关键安全措施，涵盖输入验证、跨站脚本（XSS）、跨站请求伪造（CSRF）防护、HTTPS加密、文件上传控制及数据库安全等常见安全问题。通过使用express-validator、helmet、csurf、multer等主流中间件与工具，帮助开发者构建更安全的后端服务。项目经过实际测试，适用于学习和生产环境的安全加固实践。

Node.js 应用安全实战：从输入防御到纵深加固

在今天这个万物互联的时代，一个简单的登录接口背后可能承载着数百万用户的信任。而作为现代 Web 后端的主力引擎之一，Node.js 凭借其非阻塞 I/O 和事件驱动模型，在高并发场景中大放异彩 🚀。但你有没有想过—— 越是灵活的技术栈，越容易成为攻击者的突破口？

我们见过太多“看起来很稳”的服务，因为一段未经校验的参数、一个被忽略的安全头、或者一次疏忽的依赖更新，最终导致数据库泄露、账户被盗、甚至服务器沦陷 💥。这并不是危言耸听，而是每天都在发生的现实。

所以，今天我们不讲理论套话，也不堆砌术语。咱们就坐下来，像两个老程序员喝咖啡那样聊聊：
👉 如何用最实在的方式，把你的 Node.js 服务从“能跑”变成“跑得稳、防得住”。

输入是第一道防线，也是最容易被突破的口子 🔐

Web 安全的第一课就是： 永远不要相信用户输入 。哪怕前端加了验证，哪怕你觉得“谁会输错呢”，攻击者总能找到绕过的方法。他们不是来用功能的，他们是来找漏洞的 😈。

比如下面这段代码，看着挺正常吧？

const moduleName = req.query.module;
require(moduleName); // oh no...

只要请求带上 ?module=child_process ，恭喜你，服务器已经准备好执行任意命令了……是不是头皮一紧？😱

这就是典型的“动态模块加载”滥用问题。Node.js 的强大运行时能力一旦失控，就成了攻击者的后门钥匙。所以我们要做的第一件事，就是建立一套完整的 输入验证 + 输出净化 防御体系。

白名单思维：只放行我知道的，其余一律拒之门外 ✅

很多团队还在用黑名单过滤敏感字符（比如删掉 <script> ），但这是个死胡同。黑客早就学会编码绕过、大小写混淆、Unicode 替换……防不胜防。

真正靠谱的做法是 白名单验证（Whitelist Validation） ——只允许预定义范围内的输入通过。

举个例子，注册用户名该怎么校验？

const usernamePattern = /^[a-zA-Z0-9_]{4,20}$/;

function validateUsername(username) {
    if (!username || typeof username !== 'string') {
        return { valid: false, reason: '用户名不能为空且必须为字符串' };
    }
    if (!usernamePattern.test(username)) {
        return { 
            valid: false, 
            reason: '用户名只能包含字母、数字和下划线，长度为4-20位' 
        };
    }
    return { valid: true };
}

你看，这里没有去“删掉危险字符”，而是直接说：“不符合格式？抱歉，不行。”
这种“默认拒绝”的哲学，才是安全设计的核心。

字段	允许字符	最小长度	最大长度	是否允许特殊符号
用户名	字母、数字、下划线	4	20	否
密码	所有可见ASCII字符	8	64	是（推荐复杂度）
邮箱	标准邮箱格式字符	5	254	是（@.等必需）

而且记住一点： 最小权限输入控制 。别问身份证号除非真需要，别要家庭住址除非业务强依赖。每多收一个字段，就多一分泄露风险。

顺便提一句，不只是表单数据，HTTP 方法、Header、Content-Type 这些元信息也得管！

app.use('/api/user', (req, res, next) => {
    const allowedMethods = ['GET', 'POST'];
    if (!allowedMethods.includes(req.method)) {
        return res.status(405).json({ error: 'Method Not Allowed' });
    }
    next();
});

连 PUT 和 DELETE 都拦在外面，攻击者想搞破坏都没机会下手 👊。

类型校验不能靠猜，边界检查才是王道 🔢

JavaScript 是弱类型语言，这意味着你可以传 "1" 当作 1 ，也可以让 {} 冒充数组。这对开发者友好，对攻击者更友好。

设想一下这个场景：

function validateOrderQuantity(quantity) {
    const num = Number(quantity);
    if (isNaN(num)) {
        return { valid: false, reason: '数量必须为有效数字' };
    }
    if (!Number.isInteger(num)) {
        return { valid: false, reason: '数量必须为整数' };
    }
    if (num < 1 || num > 1000) {
        return { valid: false, reason: '数量应在1到1000之间' };
    }
    return { valid: true, value: num };
}

如果不做这些判断，有人提交 quantity="1 OR 1=1" ，拼进 SQL 查询里就成了灾难性的注入攻击。

当然啦，手动写这么多判断太累人了。这时候就得请出神器： Joi 或 Zod 。

const Joi = require('joi');

const orderSchema = Joi.object({
    productId: Joi.string().uuid().required(),
    quantity: Joi.number().integer().min(1).max(1000).required(),
    price: Joi.number().positive().precision(2).required()
});

const { error, value } = orderSchema.validate(req.body);
if (error) {
    return res.status(400).json({ error: error.details[0].message });
}

声明式验证 + 自动报错，既省事又可靠，简直是 API 接口的标配装备 ⚙️。

下面是整个校验流程的可视化路径：

graph TD
    A[接收用户输入] --> B{是否为空?}
    B -- 是 --> C[返回缺失字段错误]
    B -- 否 --> D[执行类型转换]
    D --> E{类型是否合法?}
    E -- 否 --> F[返回类型错误]
    E -- 是 --> G[执行边界检查]
    G --> H{是否在允许范围内?}
    H -- 否 --> I[返回越界错误]
    H -- 是 --> J[进入业务逻辑处理]

层层递进，步步设防。只有全部通关的数据，才配接触核心逻辑 💪。

express-validator：让验证变得优雅又高效 ✨

说实话，我以前也手写验证逻辑，直到用了 express-validator ，才发现什么叫“生产力跃迁”。

先装包：

npm install express-validator

然后在路由里链式定义规则：

const { check, validationResult } = require('express-validator');

app.post('/register', [
    check('email')
        .isEmail()
        .normalizeEmail()
        .withMessage('请输入有效的邮箱地址'),
    check('password')
        .isLength({ min: 8 })
        .matches(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/)
        .withMessage('密码至少8位，需包含大小写字母和数字'),
    check('age')
        .optional()
        .isInt({ min: 18, max: 120 })
        .withMessage('年龄须为18-120之间的整数')
], (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
        return res.status(400).json({ errors: errors.array() });
    }

    // 此处执行注册逻辑
    res.status(201).json({ message: '注册成功' });
});

简洁明了，语义清晰。 .check() 定义字段， .isEmail() 判断格式， .optional() 表示可选，最后统一收集错误。

更绝的是，它还支持异步自定义校验！比如检查邮箱是否已被注册：

const User = require('./models/User');

check('email').custom(async (value) => {
    const existingUser = await User.findOne({ where: { email: value } });
    if (existingUser) {
        throw new Error('该邮箱已被注册');
    }
    return true;
})

.custom() 接收异步函数，自动等待 Promise 返回结果。数据库查重、验证码验证、第三方风控联动，通通搞定 ✔️。

错误响应也要讲究策略：别暴露系统细节 ❌

很多人忽略了这一点： 错误信息本身也可能成为攻击线索 。

看看这两个对比：

❌ 不安全：

{ "error": "Column 'admin_flag' cannot be null" }

✅ 安全：

{ "error": "提交数据不完整，请检查输入项" }

前者直接告诉攻击者：“哦，原来这张表有个叫 admin_flag 的字段！” 下一步可能就是提权尝试。

正确的做法是： 脱敏处理 + 统一抽象 。所有内部异常都转成通用提示，同时记录详细日志供排查。

app.use((err, req, res, next) => {
    console.error(err.stack); // 仅记录日志
    res.status(500).json({ error: '服务器内部错误' });
});

前端收到的永远是干净、结构化的错误：

{
  "errors": [
    {
      "value": "abc",
      "msg": "密码至少8位",
      "param": "password",
      "location": "body"
    }
  ]
}

精准定位问题，又不会泄露任何架构信息。这才是专业级 API 的样子 🧠。

输出也要净化：别让 HTML 成为 XSS 的温床 🛡️

现在富文本越来越常见，博客、评论、公告栏……但如果不对内容做清理，随便插入 <img src=x onerror=alert(1)> 就能弹窗，持久型 XSS 分分钟上线。

解决方案？用 DOMPurify 在服务端做净化！

npm install dompurify jsdom

const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');

const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

const dirty = '<img src=x onerror=alert(1)> <b>合法内容</b>';
const clean = DOMPurify.sanitize(dirty);

console.log(clean); // 输出: <b>合法内容</b>

它会自动移除所有事件属性（ onclick , onload ）、危险标签（ <script> , <iframe> ），只保留安全元素。

建议采用双端协同净化策略：

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: 提交含HTML的内容
    Server->>Server: 使用DOMPurify净化
    Server->>Database: 存储净化后内容
    Database-->>Server: 返回数据
    Server->>Client: 发送净化内容
    Client->>Client: 前端再次净化（可选）
    Client->>UI: 渲染安全内容

即使前端做了处理，服务端仍需独立净化。毕竟攻击者完全可以绕过前端，直连 API。

这就叫“纵深防御”——你不信客户端，我不信网络，咱各自守好自己的岗哨 🛡️🛡️。

HTTP 层面的攻防博弈：看不见的战场更危险 🕵️‍♂️

你以为安全只发生在代码里？错。 HTTP 协议本身就是一个巨大的攻击面 。中间人、点击劫持、资源劫持、CSRF……这些都不是虚构故事。

所幸浏览器提供了一系列安全头机制，只要正确配置，就能让大多数传统攻击失效。

CSP：内容安全策略，XSS 的终极克星 🔐

如果说防火墙是围墙，那 CSP（Content-Security-Policy）就是给每个砖块贴上“允许使用”的标签。

来看一个典型的 CSP 设置：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.***; object-src 'none'; style-src 'self' 'unsafe-inline'; img-src *; frame-ancestors 'none';

指令	作用
`default-src 'self'`	默认只允许同源资源
`script-src`	控制哪些地方可以加载 JS
`object-src 'none'`	禁止 Flash、PDF 插件等潜在风险组件
`frame-ancestors 'none'`	防止页面被嵌入 iframe（防点击劫持）

执行流程如下：

graph TD
    A[浏览器发起请求] --> B[服务器返回HTML+响应头]
    B --> C{是否包含CSP头？}
    C -->|是| D[解析CSP策略]
    D --> E[构建可信资源源列表]
    E --> F[加载脚本/样式/图片等资源]
    F --> G{资源URL是否在白名单中？}
    G -->|否| H[阻止加载或执行]
    G -->|是| I[正常渲染]
    H --> J[控制台输出CSP违规日志]

比如你想引入 Google Analytics，但忘了加域名白名单？浏览器直接拦截，并上报违规日志。

还可以开启报告功能，实时监控攻击尝试：

Content-Security-Policy: default-src 'self'; report-uri /csp-violation-report-endpoint

每次违规都会 POST 一条 JSON 日志过来，方便你分析潜在威胁。

其他关键安全头也不能少 🔝

虽然 CSP 很强，但老派安全头依然有用武之地，特别是在兼容老旧浏览器时。

头名称	推荐值	功能
`X-Content-Type-Options`	`nosniff`	禁止MIME嗅探，防止 `.jpg` 被当作 JS 执行
`X-Frame-Options`	`DENY`	防止被 iframe 嵌套
`X-XSS-Protection`	`1; mode=block`	启用浏览器内置 XSS 过滤器（已弃用但仍支持）

设置方式也很简单：

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('X-XSS-Protection', '1; mode=block');
  next();
});

不过手动维护太麻烦？那就用 helmet 一键搞定！

npm install helmet

const helmet = require('helmet');
app.use(helmet());

这一句相当于启用了十几个安全头，包括：

Content-Security-Policy
Strict-Transport-Security （HSTS）
X-Frame-Options
X-Content-Type-Options
X-Powered-By 移除（隐藏技术栈）

还能定制化配置，比如允许特定 CDN 加载脚本：

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      'default-src': ["'self'"],
      'script-src': ["'self'", "https://www.googletagmanager.***"],
      'img-src': ["'self'", "data:", "https:"],
      'connect-src': ["'self'", "https://api.example.***"]
    }
  })
);

甚至可以用 nonce 机制替代 'unsafe-inline' ，进一步提升安全性：

app.use((req, res, next) => {
  res.locals.nonce = crypto.randomBytes(16).toString('hex');
  next();
});

// CSP 中引用 nonce
'script-src': [`'self'`, `'nonce-${res.locals.nonce}'`]

模板中这样写：

<script nonce="<%= nonce %>">
  console.log("Safe inline script");
</script>

每次生成唯一令牌，杜绝全局内联脚本的风险。高级玩家必备技巧 ✨。

CSRF 攻击：你以为用户在操作，其实是黑客在操控 🎭

有没有一种攻击，不需要窃取密码、不需要入侵服务器，就能让用户自己完成转账、改密、删账号？

有，那就是 CSRF（跨站请求伪造） 。

想象这个场景：你登录了银行网站，然后打开另一个恶意网页。那个页面悄悄发了个请求：

<img src="https://bank.***/transfer?amount=1000&to=hacker" />

浏览器自动带上你的 Cookie，请求成功执行。钱没了，你还完全不知情。

攻击链条如下：

sequenceDiagram
    participant User
    participant AttackerSite
    participant BankServer

    User->>AttackerSite: 访问恶意网页
    AttackerSite->>BankServer: 自动发起POST /transfer (带Cookie)
    BankServer-->>User: 返回200 OK (转账成功)
    Note right of User: 用户无感知完成操作

解决办法？加 CSRF Token ！

使用 csurf 中间件：

npm install csurf cookie-parser

const csrf = require('csurf');
const cookieParser = require('cookie-parser');

app.use(cookieParser());
app.use(csrf({ cookie: true }));

app.get('/form', (req, res) => {
  res.json({ csrfToken: req.csrfToken() });
});

app.post('/process', (req, res) => {
  // 自动校验_token_
  res.send('Data processed safely.');
});

每次渲染表单时下发一次性 token，提交时比对。伪造请求拿不到 token，自然无法通过。

再叠加 SameSite Cookie 属性，双重保险：

res.cookie('sessionid', 'abc123', {
  httpOnly: true,
  secure: true,
  sameSite: 'lax'  // 'strict' | 'lax' | 'none'
});

lax ：允许导航请求携带 Cookie，但阻止 POST 表单自动提交
strict ：完全禁止跨站 Cookie
none ：必须配合 HTTPS 使用

两者结合，CSRF 基本无解 🤫。

HTTPS 不是选项，是底线 🔒

还在用 HTTP？那你等于在高速公路上裸奔。

MITM（中间人攻击）轻而易举就能截获登录凭证、支付信息、JWT Token……一切明文传输的内容都是猎物。

解决方法只有一个： 全面启用 HTTPS 。

获取免费证书（Let’s Encrypt）：

sudo certbot certonly --standalone -d yourdomain.***

Node.js 启动 HTTPS 服务：

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('/etc/letsencrypt/live/yourdomain.***/privkey.pem'),
  cert: fs.readFileSync('/etc/letsencrypt/live/yourdomain.***/cert.pem')
};

https.createServer(options, app).listen(443);

再加上自动跳转中间件（express-sslify）：

npm install express-sslify

const enforce = require('express-sslify');
app.use(enforce.HTTPS({ trustProtoHeader: true }));

访问 HTTP 地址？301 强制跳转 HTTPS。

还不够！首次访问仍有被降级的风险（SSL Stripping）。怎么办？

上 HSTS（HTTP Strict Transport Security） ！

app.use(helmet.hsts({
  maxAge: 31536000,           // 一年
  includeSubDomains: true,
  preload: true
}));

一旦浏览器记住这条规则，后续访问直接强制走 HTTPS，连请求都不发出去。彻底杜绝降级攻击。

如果你提交到 HSTS Preload List ，Chrome、Firefox 等浏览器会在安装时就把你的域名列入“必须加密”名单。这才是真正的安全闭环 🔐。

文件上传：别让 `/uploads` 变成后门入口 🚪

文件上传功能几乎是每个应用都需要的，但也最容易出事。

试想：用户上传一个 .php 文件，名字改成 avatar.jpg ，服务器没检测 MIME 类型，结果这个文件能被执行……恭喜，RCE（远程代码执行）达成 🩸。

所以，文件上传必须做到五层防护：

文件名 sanitization
大小限制
类型白名单
二进制签名验证
存储目录隔离与权限控制

用 multer 实现：

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    cb(null, './uploads');
  },
  filename: (req, file, cb) => {
    const sanitizedName = file.originalname
      .replace(/[^a-zA-Z0-9.\-_]/g, '_')
      .substring(0, 100);
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    cb(null, uniqueSuffix + '-' + sanitizedName);
  }
});

const upload = multer({ 
  storage,
  limits: { fileSize: 5 * 1024 * 1024 }, // 5MB
  fileFilter: validateFileType
});

再结合 file-type 做二进制检测：

npm install file-type

const fileType = require('file-type');

const validateFileType = (req, file, cb) => {
  const allowedTypes = ['image/jpeg', 'image/png', 'image/gif'];
  const chunk = file.buffer.slice(0, 4100);
  fileType.fromBuffer(chunk).then(result => {
    if (result && allowedTypes.includes(result.mime)) {
      cb(null, true);
    } else {
      cb(new Error('文件签名不匹配'), false);
    }
  }).catch(() => cb(new Error('无法识别文件类型'), false));
};

最后，确保上传目录不可执行：

chmod 644 uploads/

Nginx 配置禁止脚本解析：

location ~ \.(php|jsp|pl)$ {
    deny all;
}

完整防御链如下：

graph TD
    A[客户端上传文件] --> B{Multer拦截}
    B --> C[检查大小与数量]
    C --> D[文件名Sanitize]
    D --> E[MIME类型白名单校验]
    E --> F[二进制头签名验证]
    F --> G[存储至非Web根目录]
    G --> H[设置文件权限644]
    H --> I[通过反向代理访问]

层层设卡，绝不留死角。

数据库交互：SQL 注入不是传说，是日常 🧨

“我用 ORM 就安全了吗？”
不一定。只要你还在拼字符串，风险就在。

看这个经典案例：

❌ 危险：

const query = `SELECT * FROM users WHERE id = ${req.query.id}`;
connection.query(query, callback);

攻击者传入 id=1 OR 1=1 ，直接查出所有用户。

✅ 正确做法：参数化查询！

const sql = 'SELECT * FROM users WHERE id = ?';
connection.execute(sql, [req.query.id], callback);

参数与 SQL 分离传输，数据库不会将其解析为代码片段。

ORM 如 Sequelize 更安全：

User.findAll({
  where: { email: req.body.email }
});
// 生成预编译语句，自动绑定参数

但注意！别滥用 sequelize.literal() 或 raw query，否则等于开后门。

动态查询也要安全封装：

const Op = require('sequelize').Op;

let conditions = {};
if (req.query.minAge) {
  conditions.age = { [Op.gte]: parseInt(req.query.minAge) };
}
if (req.query.name) {
  conditions.name = { [Op.like]: `%${req.query.name}%` };
}

User.findAll({ where: conditions }); // 安全构建复合查询

第三方依赖：百个 npm 包里，藏着多少定时炸弹？💣

你知道吗？一个普通 Node.js 项目平均依赖 超过70个间接包 。你引入一个工具库，它又依赖五个，每个又依赖七八个……最终形成一张庞大的依赖网。

而其中任何一个存在漏洞，整个系统就不安全。

运行 npm audit ：

npm audit

输出可能是这样的：

┌───────────────┬──────────────────────────────────────────────────┐
│ High          │ Prototype Pollution in dot-prop                  │
├───────────────┼──────────────────────────────────────────────────┤
│ Package       │ dot-prop                                         │
├───────────────┼──────────────────────────────────────────────────┤
│ Patched in    │ >=5.1.1                                          │
└───────────────┴──────────────────────────────────────────────────┘

修复：

npm audit fix --only=production

更进一步，集成 Snyk 做持续监控：

npm install -g snyk
snyk auth
snyk test --severity-threshold=high

CI 流水线中加入：

- name: Snyk Security Check
  run: snyk monitor
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

发现高危漏洞？自动中断部署。

再配合 Dependabot 定期升级：

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

自动化补丁管理，才能跟上漏洞爆发的速度。

最后的防线：日志、审计、红蓝对抗 🛠️

再好的防护也会有遗漏。所以我们需要三件事：

日志记录 ：关键操作都要留痕
异常监测 ：发现可疑行为及时告警
定期演练 ：模拟攻击，检验防御体系

用 winston 记录脱敏日志：

const logger = winston.createLogger({
  format: winston.format.***bine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.File({ filename: 'logs/error.log', level: 'error' }),
    new winston.transports.File({ filename: 'logs/***bined.log' })
  ]
});

app.use((req, res, next) => {
  const cleanBody = { ...req.body };
  delete cleanBody.password;
  delete cleanBody.token;
  logger.info(`${req.method} ${req.url}`, { ip: req.ip, body: cleanBody });
  next();
});

结合 morgan 记录访问流：

app.use(morgan('***bined', { stream: a***essLogStream }));

每季度做一次红蓝对抗：

渗透测试（Burp Suite + ZAP）
代码审计（SonarQube + ESLint 插件）
架构评审（最小权限、纵深防御）
应急演练（模拟数据泄露）

只有不断攻击自己，才能变得更强大 💪。

写在最后：安全不是功能，是习惯 🌱

Node.js 很强大，但它的灵活性是一把双刃剑。我们可以快速开发，也可以快速犯错。

真正的安全，不是某个中间件、不是某条规则，而是一种思维方式：

“如果这事出了问题，后果是什么？我能接受吗？”

从输入验证到输出净化，从 HTTP 头到 HTTPS，从文件上传到依赖管理……每一环都不能松懈。

希望这篇文章能帮你建立起完整的安全认知框架。不必一次做到完美，但一定要开始行动。

毕竟，用户信任你，不是因为你用了什么技术，而是因为他们相信：你会保护好他们的数据 ❤️。

“安全不是终点，而是一段永不停歇的旅程。”
—— 每一位深夜排查漏洞的工程师