DeBug 漏洞披露平台的核心任务，是把白帽子提交的漏洞报告从杂乱的信息整理成研发团队可以直接跟进的工单。如果仍然用邮件或表格接收漏洞，报告格式不统一，修复状态不透明，最后连是否修复都说不清楚。本文使用 Node.js 从零搭建一个最小可用版本，重点说明权限模型、状态流转和审计日志的实现方式。
下面会把平台拆成三个主要部分：数据模型、鉴权控制、接口流转，最后再补充生产环境必须考虑的安全加固。
一、平台需要解决的核心问题与选型理由
漏洞披露平台通常涉及三类角色。第一类是提交漏洞的白帽子，也就是外部安全研究员，他们只应该创建报告、查看自己提交的内容，而不能看到别人提交的漏洞细节。第二类是安全团队中的审核人员，他们负责判断漏洞是否真实、严重程度多高，并决定交给哪个研发人员处理。第三类是研发人员，他们只需要看到分配给自己的报告，修复完成后更新状态。
如果权限做得太粗糙，比如把所有报告暴露给所有登录用户，就可能造成严重的信息泄露。因此平台需要明确区分资源归属，在数据访问层做角色判断，而不仅仅是在前端隐藏按钮。状态流转同样重要，漏洞报告一般会经历提交、审核、确认、修复、修复完成、关闭等阶段，某些情况下还会被标记为重复或信息不足。状态不能随意跳转，否则流程就失去了意义。
Node.js 在这个场景下比较合适。一方面漏洞报告天然以 JSON 形式在前后端之间传递，Express 对 JSON 的处理非常直接；另一方面平台后续需要接入邮件通知、Webhook、消息队列等异步能力，Node.js 的事件驱动模型扩展起来比较顺手。使用 MongoDB 存储报告也较为灵活，报告字段可能随着业务变化不断调整，文档模型比关系模型更容易演进。
二、项目初始化与基础结构
先初始化项目并安装必要依赖。核心依赖包括 Express、Mongoose、jsonwebtoken、bcrypt、helmet 和 express-rate-limit。Express 负责 HTTP 路由，Mongoose 负责 MongoDB 数据访问，jsonwebtoken 用于签发和校验访问令牌，bcrypt 用于密码哈希，helmet 用于设置安全响应头，express-rate-limit 用于接口限流。
npm init -y npm install express mongoose jsonwebtoken bcrypt helmet express-rate-limit
推荐的基础目录结构如下：
src/config存放数据库连接和环境变量读取逻辑src/models存放用户和漏洞报告等 Mongoose 模型src/middleware存放鉴权、角色控制、参数校验等中间件src/controllers存放具体业务处理函数src/routes存放 API 路由定义src/utils存放审计日志、错误处理等通用工具
下面是一个简单的 Express 入口示例。中间件会按照从上到下的顺序执行，因此先挂载 helmet 和 JSON 解析器，再挂载速率限制，最后才注册业务路由。MongoDB 连接失败时直接退出进程，避免服务在未连接数据库的情况下继续接收请求。
const express = require('express');
const mongoose = require('mongoose');
const helmet = require('helmet');
const rateLimit = require('express-rate-limit');
const reportRoutes = require('./routes/reports');
const authRoutes = require('./routes/auth');
const app = express();
app.use(helmet());
app.use(express.json({ limit: '1mb' }));
const apiLimiter = rateLimit({
windowMs: 15 * 60 * 1000,
max: 200,
message: { error: '请求过于频繁，请稍后再试' }
});
app.use('/api', apiLimiter);
mongoose.connect(process.env.MONGO_URI, {
useNewUrlParser: true,
useUnifiedTopology: true
})
.then(function () {
console.log('MongoDB connected');
})
.catch(function (err) {
console.error(err);
process.exit(1);
});
app.use('/api/auth', authRoutes);
app.use('/api/reports', reportRoutes);
app.listen(process.env.PORT || 3000, function () {
console.log('DeBug server running');
});
环境变量需要单独配置，避免把数据库密码、JWT 密钥写进代码仓库。可以使用 dotenv 在启动时加载 .env 文件，并用 process.env 读取。
三、用户与漏洞报告的数据模型
用户模型需要区分角色，角色决定了一个账号能执行哪些操作。密码不能保存明文，应该使用 bcrypt 生成哈希，登录时再用 compare 方法验证。用户文档至少包含用户名、邮箱、密码哈希和角色字段。角色可以定义为 REPORTER、TRIAGER 和 DEVELOPER 三种。
const mongoose = require('mongoose');
const bcrypt = require('bcrypt');
const userSchema = new mongoose.Schema({
username: { type: String, required: true, unique: true, trim: true },
email: { type: String, required: true, unique: true, lowercase: true },
passwordHash: { type: String, required: true },
role: { type: String, enum: ['REPORTER', 'TRIAGER', 'DEVELOPER'], default: 'REPORTER' }
}, { timestamps: true });
userSchema.methods.comparePassword = function (candidate) {
return bcrypt.compare(candidate, this.passwordHash);
};
module.exports = mongoose.model('User', userSchema);
漏洞报告模型是平台的核心。标题、描述和影响级别是最基本的字段，影响级别可以限定为低、中、高、严重四个选项，避免用户随意输入。状态字段使用枚举约束，确保数据库里不会出现非法状态。除了报告创建者和当前处理人，还需要一个审计日志数组，把每一次状态流转、评论和分配行为都记录下来，方便事后追溯。
const mongoose = require('mongoose');
const reportSchema = new mongoose.Schema({
title: { type: String, required: true, trim: true, maxlength: 200 },
description: { type: String, required: true, maxlength: 8000 },
impact: { type: String, enum: ['low', 'medium', 'high', 'critical'], required: true },
status: {
type: String,
enum: ['SUBMITTED', 'TRIAGED', 'CONFIRMED', 'FIXING', 'FIXED', 'CLOSED', 'DUPLICATE', 'INFORMATIVE'],
default: 'SUBMITTED'
},
reporter: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
assignee: { type: mongoose.Schema.Types.ObjectId, ref: 'User', default: null },
auditLog: [
{
action: String,
operator: { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
comment: String,
createdAt: { type: Date, default: Date.now }
}
]
}, { timestamps: true });
module.exports = mongoose.model('Report', reportSchema);
鉴权中间件的作用是解析请求头中的 Bearer Token，验证签名的有效性，然后根据 Token 中的用户 ID 查询数据库。只有查询到真实用户后，才把用户对象挂到 req.user 上并放行。角色控制中间件则进一步判断当前用户是否具备指定角色，适合用来保护只有审核人员才能访问的接口。
const jwt = require('jsonwebtoken');
const User = require('../models/User');
function requireAuth(req, res, next) {
const authHeader = req.headers.authorization || '';
if (!authHeader.startsWith('Bearer ')) {
return res.status(401).json({ error: '缺少访问令牌' });
}
const token = authHeader.slice(7);
try {
const payload = jwt.verify(token, process.env.JWT_SECRET);
User.findById(payload.sub)
.then(function (user) {
if (!user) {
return res.status(401).json({ error: '用户不存在' });
}
req.user = user;
next();
})
.catch(function () {
res.status(401).json({ error: '认证失败' });
});
} catch (err) {
return res.status(401).json({ error: '令牌无效' });
}
}
function requireRole(role) {
return function (req, res, next) {
if (!req.user || req.user.role !== role) {
return res.status(403).json({ error: '无权限执行此操作' });
}
next();
};
}
module.exports = { requireAuth, requireRole };
四、报告提交与状态流转接口
创建报告接口只允许已登录用户调用。服务端不能直接信任客户端传来的所有字段，至少要校验标题、描述、影响级别是否存在，并且影响级别必须在白名单内。创建报告时，除了保存基础字段，还应该写入第一笔审计日志，标记为 CREATED，这样每一份报告从创建开始就有完整的操作记录。
const express = require('express');
const Report = require('../models/Report');
const { requireAuth, requireRole } = require('../middleware/auth');
const router = express.Router();
router.post('/', requireAuth, async function (req, res) {
const { title, description, impact } = req.body;
if (!title || !description || !impact) {
return res.status(400).json({ error: '标题、描述和影响级别均为必填项' });
}
const allowedImpact = ['low', 'medium', 'high', 'critical'];
if (allowedImpact.indexOf(impact) === -1) {
return res.status(400).json({ error: '影响级别不合法' });
}
try {
const report = await Report.create({
title: title.trim(),
description: description.trim(),
impact: impact,
reporter: req.user._id,
auditLog: [
{
action: 'CREATED',
operator: req.user._id,
comment: '漏洞报告提交'
}
]
});
res.status(201).json({ id: report._id, status: report.status });
} catch (err) {
res.status(500).json({ error: '创建失败，请稍后重试' });
}
});
状态更新接口要复杂一些。一个报告不能从 SUBMITTED 直接跳到 FIXED，必须经过审核、确认和修复等中间阶段。可以在代码里维护一个状态转移白名单，只允许特定状态进入特定下一状态。审核人员操作时还必须填写备注，说明为什么流转，这样后续发生争议时可以回溯。
此外，这个接口要使用 requireRole('TRIAGER') 进行角色限制。普通白帽子不能修改自己报告的状态，研发人员也不能自己把未修复的报告改成已修复，否则平台流程就形同虚设。每次状态变更都要向 auditLog 追加一条记录，动作类型可以定义为 STATUS_CHANGED。
router.patch('/:id/status', requireAuth, requireRole('TRIAGER'), async function (req, res) {
const allowedTransitions = {
SUBMITTED: ['TRIAGED', 'DUPLICATE', 'INFORMATIVE'],
TRIAGED: ['CONFIRMED', 'INFORMATIVE'],
CONFIRMED: ['FIXING'],
FIXING: ['FIXED'],
FIXED: ['CLOSED']
};
const { status, comment } = req.body;
if (!status || !comment) {
return res.status(400).json({ error: '状态和操作备注为必填项' });
}
try {
const report = await Report.findById(req.params.id);
if (!report) {
return res.status(404).json({ error: '报告不存在' });
}
const nextStatuses = allowedTransitions[report.status] || [];
if (nextStatuses.indexOf(status) === -1) {
return res.status(400).json({ error: '不允许从 ' + report.status + ' 流转到 ' + status });
}
report.status = status;
report.auditLog.push({
action: 'STATUS_CHANGED',
operator: req.user._id,
comment: comment
});
await report.save();
res.json({ id: report._id, status: report.status });
} catch (err) {
res.status(500).json({ error: '状态更新失败' });
}
});
详情查询接口不能简单地根据 ID 返回数据，否则任何登录用户都能遍历接口查看所有报告。正确的做法是先取出报告，然后比较当前用户 ID 是否等于报告创建者、是否为审核人员、是否为当前处理人。三种条件都不满足时返回 403。这样即使存在越权尝试，也会在服务端被拦截。
router.get('/:id', requireAuth, async function (req, res) {
try {
const report = await Report.findById(req.params.id)
.populate('reporter', 'username email')
.populate('assignee', 'username email');
if (!report) {
return res.status(404).json({ error: '报告不存在' });
}
const isReporter = String(report.reporter._id) === String(req.user._id);
const isTriager = req.user.role === 'TRIAGER';
let isDeveloper = false;
if (report.assignee) {
isDeveloper = String(report.assignee._id) === String(req.user._id);
}
if (isReporter || isTriager || isDeveloper) {
return res.json({ report: report });
}
return res.status(403).json({ error: '无权查看该报告' });
} catch (err) {
res.status(500).json({ error: '查询失败' });
}
});
五、安全加固与生产部署建议
接口上线前需要做好输入校验和 NoSQL 注入防护。Mongoose 的类型约束虽然能拦截一部分异常数据，但如果代码里直接使用用户输入构建查询条件，仍然可能被构造 $where、$regex 等操作符攻击。比较稳妥的做法是，对查询参数做白名单过滤，对字符串字段使用 escape 或显式类型转换，并且禁止把整个请求体直接传给 find 方法。
除了业务逻辑本身，速率限制和审计日志也不能缺失。登录接口和报告创建接口容易被滥用，应该设置更严格的限制。审计日志除了记录操作者、动作和时间，还应该记录 IP 地址和 User-Agent，方便异常行为分析。如果平台需要对外公开，建议再把 Nginx 或 API 网关放在 Node.js 前面，统一处理 HTTPS、请求压缩和负载均衡。
部署时可以使用 PM2 管理 Node.js 进程，设置自动重启和日志收集。MongoDB 需要开启认证，并限制网络访问来源。JWT 密钥、数据库连接字符串、SMTP 配置等敏感信息一律通过环境变量注入。代码仓库中只保留示例配置，不要把真实密钥提交进去。完成这些基础工作后，DeBug 平台就能从开发环境平稳过渡到生产环境，后续还可以继续扩展邮件通知、Webhook 推送和漏洞去重等功能。