1. 项目概述为什么Juice Shop是Web安全学习的“金矿”如果你正在学习Web安全或者是一名开发者想提升自己代码的安全性那么OWASP Juice Shop这个项目你一定不陌生。它被官方称为“现代Web应用中最不安全的应用”但这恰恰是它最大的价值所在。与其说它是一个漏洞百出的“烂摊子”不如说它是一个精心设计的、用于教学和实战演练的“安全靶场”。很多朋友上手Juice Shop可能只是按照攻略快速通关拿到了几个Flag但往往忽略了那些隐藏在看似简单功能背后的、极具代表性的安全逻辑缺陷。这些漏洞恰恰是真实开发中最容易犯、也最容易被安全扫描工具误判或漏报的“灰犀牛”。今天我们不聊那些显而易见的SQL注入或XSS而是聚焦于我在多次内部红蓝对抗和代码审计中从Juice Shop里挖出的5个最容易被忽略的Web安全漏洞。这些漏洞的“忽略”一方面是因为它们不直接导致服务器被“黑”危害看似不直接另一方面修复它们往往需要开发者对业务逻辑、框架机制有更深的理解而不是简单地套用安全库。我将结合Juice Shop的具体实例拆解每一个漏洞的原理、复现手法并给出能直接应用到生产环境的修复方案。你会发现安全不仅仅是安全团队的事更是每一位开发者的基本功。2. 漏洞一不安全的直接对象引用与权限校验缺失2.1 漏洞原理为什么“越权”总在细节处发生不安全的直接对象引用在OWASP Top 10中常被提及但很多开发者认为“我们用了UUID或者用了复杂的ID就不会有问题”。这是一种典型的误解。IDOR的核心不在于ID是否可预测而在于服务器是否在每次处理用户对某个对象的请求时都严格校验了当前用户是否有权访问这个特定的对象ID。Juice Shop里有一个经典场景用户订单查询。假设一个用户正常访问/api/orders/123查看自己的订单。一个安全意识不足的开发者可能会这样实现后端逻辑从请求路径或参数中获取订单ID123。直接去数据库查询SELECT * FROM orders WHERE id 123。将查询结果返回给前端。问题出在哪里服务器完全信任了客户端传来的订单ID而没有验证这个ID为123的订单其user_id字段是否等于当前登录用户的ID。攻击者只需要将浏览器地址栏的ID从123改为124就可能看到其他用户的订单信息。这就是一个典型的水平越权漏洞。更隐蔽的一种情况是“间接IDOR”。例如在修改收货地址的功能中提交的表单里包含一个隐藏的addressId字段。攻击者拦截请求将这个addressId修改为其他人的地址ID并提交。如果后端仅根据这个ID更新数据库而没有校验地址所属人就会导致其他用户的地址信息被篡改。注意使用GUID/UUID并不能防止IDOR。它只能让攻击者无法轻易枚举出有效的对象ID如从123猜到124但如果攻击者通过其他信息泄露如评论、分享链接拿到了一个有效的UUID越权访问依然会发生。核心防御手段永远是权限校验。2.2 Juice Shop实战复现挖出你的“他人订单”在Juice Shop中这个漏洞的体现非常直接。首先以任意用户身份例如注册账号testexample.com登录。完成一次购物生成至少一个订单。进入“Order History”页面。打开浏览器开发者工具F12切换到Network网络选项卡。在订单历史页面你会看到浏览器发起了一个类似GET /rest/order-history/1的请求。这里的1很可能就是你的订单ID。尝试将这个请求的ID修改为其他数字例如2然后重新发送这个请求在开发者工具中可以直接右键请求选择“Edit and Resend”。观察响应。如果你收到了另一个订单的详细信息包含商品、地址、价格等那么IDOR漏洞就存在了。实操心得在测试时不要只改一个数字。可以尝试使用Burp Suite的Intruder模块设置一个数字序列进行模糊测试快速发现可访问的订单ID范围。同时注意响应中的HTTP状态码。即使是403 Forbidden也比直接返回数据要安全。但最理想的情况是后端对于任何不属于当前用户的资源ID请求都返回统一的“未找到”提示如404避免泄露资源是否存在的信息。2.3 修复方案从“信任”到“验证”的代码改造修复的核心思想是后端绝不能信任客户端传来的任何用于定位资源的标识符必须在数据库查询中加入用户上下文约束。错误示例易受攻击// 伪代码危险 app.get(/api/orders/:orderId, (req, res) { const orderId req.params.orderId; db.getOrderById(orderId).then(order { res.json(order); // 直接返回未校验用户 }); });正确示例安全// 伪代码安全 app.get(/api/orders/:orderId, authenticateUser, (req, res) { const orderId req.params.orderId; const currentUserId req.session.userId; // 从认证中间件获取当前用户ID db.getOrderByIdAndUser(orderId, currentUserId).then(order { // 查询条件同时包含ID和用户ID if (!order) { // 统一返回404不暴露“订单存在但无权访问”的信息 return res.status(404).json({ message: Order not found }); } res.json(order); }); });关键改造点查询层改造将getOrderById(id)改为getOrderByIdAndUser(id, userId)。确保数据库查询语句类似SELECT * FROM orders WHERE id ? AND user_id ?。ORM/ODM使用如果你使用Sequelize、Mongoose等ORM确保在findOne或findById时将用户ID作为查询条件的一部分。统一的错误响应无论是因为订单不存在还是因为无权访问都返回相同的错误信息如404这被称为“失败模糊化”可以防止攻击者通过错误信息差异来推断资源状态。中间件抽象对于RESTful API可以编写一个通用的授权中间件。例如authorize(‘Order’, ‘orderId’)该中间件会自动从路径参数中获取orderId从会话中获取userId并执行权限校验。这个修复方案需要开发者对每个涉及资源对象访问的接口进行排查和改造虽然工作量不小但这是构建安全应用的基石。3. 漏洞二安全配置错误与敏感信息泄露3.1 漏洞原理默认配置、冗余接口与调试信息安全配置错误是一个大类它涵盖了一切因不当配置而引入的风险。在Juice Shop和真实应用中这常常体现在默认凭证未修改的管理后台、数据库、中间件的默认用户名/密码。不必要的服务开启的调试接口、管理接口如/actuator/phpinfo/admin、旧的测试API。过度的错误信息将包含堆栈跟踪、SQL语句、服务器路径等敏感信息的错误详情直接返回给客户端。不安全的安全头缺失Content-Security-Policy、X-Frame-Options、X-Content-Type-Options等关键安全头。目录遍历与源码泄露配置不当导致可以通过类似../../的路径遍历访问系统文件或者.git、.DS_Store、备份文件如index.php.bak被直接访问。这些漏洞之所以“容易被忽略”是因为它们通常不直接存在于业务代码中而是与部署环境、框架配置、运维习惯强相关。开发者在本地调试时需要详细错误信息但上线时忘记关闭调试模式运维人员为了省事直接使用默认配置。攻击者往往利用这些“低垂的果实”获取初步立足点或敏感信息。3.2 Juice Shop实战复现寻找被遗忘的“后门”与信息在Juice Shop中我们可以通过以下几种方式发现配置错误目录与文件枚举使用工具如gobuster、dirsearch或手工猜测尝试访问常见路径。访问/ftp目录你会发现一个可以列出文件目录的接口里面可能存放了敏感的配置文件或说明文档。尝试访问/package.json、/.env、/backup.zip等看是否能直接下载到源码或环境变量文件。分析错误响应故意触发一些错误例如在搜索框输入一个单引号‘或者访问一个不存在的API端点。观察返回的HTTP响应体是否包含了详细的SQL错误、代码行号或文件路径检查HTTP响应头使用浏览器开发者工具或curl -I命令检查关键安全头是否缺失。curl -I http://your-juice-shop-url重点关注X-Frame-Options防点击劫持、X-Content-Type-Options防MIME类型混淆、Content-Security-Policy等。寻找管理接口尝试访问/admin、/console、/actuator、/phpmyadmin等常见的管理、监控或调试入口。实操心得敏感信息泄露往往是连锁反应的起点。从package.json泄露的依赖版本可以帮助攻击者查找已知漏洞从错误信息中泄露的绝对路径可能为后续的文件包含漏洞利用提供帮助从.git文件夹泄露的源码可以让攻击者进行白盒审计发现更隐蔽的逻辑漏洞。因此信息收集阶段一定要细致。3.3 修复方案构建安全的部署与运行清单修复安全配置错误需要开发和运维协同建立一份“上线前安全检查清单”。1. 应用层配置关闭调试模式确保生产环境的框架如Spring Boot的productionprofile Node.js的NODE_ENVproduction已禁用调试功能和详细错误回显。在Express中可以设置app.set(env, production); // 自定义错误处理中间件返回友好而模糊的错误页面 app.use((err, req, res, next) { console.error(err.stack); // 错误日志记录在服务器端 res.status(500).send(Something broke!); });清理冗余文件在构建部署包时使用.dockerignore或构建脚本确保不将.git、node_modules、.env、IDE配置文件、测试代码等打包进生产环境镜像或目录。安全HTTP头使用Helmet.jsNode.js等中间件自动设置安全头。const helmet require(helmet); app.use(helmet());对于其他语言也应在Web服务器Nginx/Apache或应用层进行相应配置。2. 依赖与组件配置更新与精简定期使用npm audit、snyk、dependabot等工具扫描依赖漏洞并及时更新。移除package.json中不必要的依赖。修改默认配置对所有使用的中间件、数据库、缓存服务第一件事就是修改默认端口、密码和账号。禁用不需要的功能模块。3. 运维与架构配置最小权限原则运行应用的进程账户应具有最小必要权限。数据库连接账户应为应用创建专属账户只授予必要的CRUD权限而非root或sa。网络隔离管理接口、数据库端口不应暴露在公网。使用私有子网、安全组、防火墙规则进行隔离。如果必须开放则通过VPN或堡垒机访问。定期扫描将静态应用安全测试和动态应用安全测试纳入CI/CD流程。使用工具对生成的环境进行自动化安全扫描。4. 应急与日志配置安全的日志记录确保日志中不记录密码、信用卡号等敏感信息。同时日志本身应被妥善保护防止未授权访问。监控与告警对异常的访问模式如大量404错误、对敏感路径的扫描设置监控告警。这套方案的实施意味着将安全作为交付流程中的一个固有环节而不是事后补救。4. 漏洞三失效的访问控制与业务逻辑滥用4.1 漏洞原理当“功能”成为漏洞的跳板失效的访问控制比简单的IDOR更进一层它涉及整个应用的角色、权限模型和状态机是否被正确执行。常见场景包括垂直越权普通用户能访问或调用仅限管理员使用的功能API。状态机绕过例如在购物流程中未支付订单的状态可以被直接修改为“已发货”或者绕过身份验证步骤直接访问后续流程的页面。业务逻辑滥用利用业务规则的不严谨实现恶意操作。例如Juice Shop中的“无限优惠券”漏洞本质是后端没有对“应用优惠券”这一动作做次数或状态校验。这类漏洞的根源在于服务端对客户端请求所代表的“业务意图”和“用户上下文”缺乏连贯、完整的校验。每个API端点可能单独做了权限检查但一系列操作组合起来形成的业务流其安全性却被忽略了。攻击者通过精心构造的请求序列就可以达到非法的业务目的。4.2 Juice Shop实战复现破解“无限折扣”与“管理员伪装”我们来看两个Juice Shop中的经典案例案例一无限优惠券滥用在Juice Shop中找到可以输入优惠券代码的地方通常在购物车或结算页面。假设你找到了一个有效的优惠券代码“NEWYEAR2024”能打9折。正常流程输入代码点击应用价格更新。攻击流程 a. 打开浏览器开发者工具的网络选项卡。 b. 应用一次优惠券捕获到发送的HTTP POST请求例如到/api/coupons/apply。 c. 分析请求发现它可能只发送了优惠券代码和订单ID。 d.关键步骤不刷新页面直接重放Replay这个请求多次。 e. 观察响应和订单总额。如果总额持续下降例如从100降到90再降到81…说明服务端没有校验该优惠券是否已在本订单中使用过导致了重复应用实现了“无限折扣”。案例二伪装管理员身份注册一个普通用户并登录。检查浏览器本地存储LocalStorage、会话存储SessionStorage或Cookie。Juice Shop可能将用户信息如角色role以JWT Token或明文形式存储在客户端。如果发现role: ‘customer’这样的字段尝试将其修改为role: ‘admin’。刷新页面或访问管理功能页面如/admin。如果成功进入说明服务端完全信任了客户端传来的角色信息而没有在每次关键操作时从会话或数据库重新验证用户角色。实操心得测试业务逻辑漏洞思维要像“破解规则”而不是“寻找Bug”。你需要理解应用的正常业务流程如注册-登录-浏览-加购-下单-支付-收货-评价然后思考在每个环节如果跳过、重复或乱序执行某个步骤会发生什么自动化工具很难发现这类漏洞必须依靠手工测试和对业务的理解。4.3 修复方案实施全链路的服务端状态控制修复的核心是服务端必须成为业务逻辑和状态唯一的、权威的掌控者。客户端的所有操作请求都必须经过服务端基于完整上下文的重校验。1. 防重复提交与幂等性设计幂等令牌对于“应用优惠券”、“提交订单”、“支付”等非幂等操作要求客户端在请求中携带一个服务端下发的唯一令牌如UUID。服务端处理请求前检查该令牌是否已被使用过使用后立即使其失效。// 服务端生成并下发令牌 const idempotencyKey uuidv4(); // 存储在Redis或内存中设置较短过期时间 await redis.setex(idempotency:${userId}:${orderId}, 300, idempotencyKey); // 将idempotencyKey返回给客户端 // 客户端请求时携带该令牌 // 服务端处理请求前校验 const used await redis.get(idempotency:${userId}:${orderId}); if (used idempotencyKeyFromRequest) { return res.status(409).json({ message: Request already processed }); }数据库唯一约束在数据库层面可以为“订单-优惠券”关联表设置(order_id, coupon_code)的唯一索引从根源上防止重复关联。2. 强化角色与权限校验服务端会话权威用户的角色和权限信息必须存储在服务端会话中如Redis Session或通过加密签名如JWT确保客户端无法篡改。绝不能信任客户端传来的任何关于其权限的明文信息。基于角色的访问控制在路由或控制器层面使用中间件进行统一的角色校验。const authorize (...allowedRoles) { return (req, res, next) { const userRole req.session.user.role; // 从服务端会话获取 if (!allowedRoles.includes(userRole)) { return res.status(403).json({ message: Forbidden }); } next(); }; }; app.get(/api/admin/users, authorize(admin), (req, res) { // 只有admin角色能进入 });关键操作日志与二次验证对于敏感操作如删除用户、修改核心配置除了角色校验还应记录详细的操作日志并考虑引入二次验证如邮箱/短信验证码。3. 业务状态机服务端校验为订单、用户等核心业务实体定义明确的状态如cart,paid,shipped,delivered。任何改变状态的操作都必须校验当前状态是否允许过渡到目标状态。这应该在服务端的业务逻辑层实现最好有统一的状态机库来管理。// 伪代码使用状态机思想 function shipOrder(orderId, userId) { const order getOrder(orderId, userId); if (order.status ! paid) { throw new Error(Only paid orders can be shipped.); } // ...执行发货逻辑 order.status shipped; saveOrder(order); }通过将业务规则固化在服务端代码中并确保每个请求都在正确的上下文里被处理可以极大程度地消除因客户端不可信而导致的逻辑漏洞。5. 漏洞四安全日志记录与监控的缺失5.1 漏洞原理看不见的攻击就无法防御这是一个非常容易被忽略的“非直接”漏洞。即使你的应用代码本身没有严重漏洞但如果你不知道谁在访问、做了什么、是否异常那么你就是在“盲打”。攻击者可以进行长时间的慢速扫描、撞库攻击、逻辑漏洞试探而你可能毫无察觉直到数据被拖库或服务被破坏才发现。安全日志记录与监控的缺失主要体现在日志内容不足只记录了INFO级别的普通请求没有记录失败登录、越权访问尝试、输入验证失败、关键业务操作登录、支付、修改密码、数据导出等安全事件。日志格式不统一难以进行自动化分析和告警。日志中缺乏关键上下文没有记录源IP、用户ID、时间戳、请求体脱敏后、操作结果等。没有实时监控与告警日志只是躺在文件里没有人去看也没有系统去分析其中的异常模式。在Juice Shop的挑战中有些挑战就需要你触发特定的错误或进行异常操作而这些操作如果被妥善记录和监控就应该是管理员发现攻击迹象的线索。5.2 Juice Shop实战复现你的攻击行为被“看见”了吗你可以通过以下方式自我检验Juice Shop或你自己的应用的日志监控水平触发一系列“可疑”事件使用无效凭证进行多次登录尝试撞库攻击模拟。尝试访问/admin、/phpinfo等管理或敏感路径。在输入框中提交明显的SQL注入或XSS载荷如‘ OR 11 --,scriptalert(1)/script。完成一个高价值的业务操作比如兑换一个昂贵的奖品或使用一个超级优惠券。检查日志输出如果Juice Shop是本地运行查看其控制台输出。它是否将上述事件以WARN或ERROR级别打印出来日志里是否包含了你的IP、尝试的用户名、请求的路径和参数如果是你自己的应用登录到服务器查看应用日志文件如/var/log/yourapp.log或集中式日志平台如ELK、Splunk。你能轻松找到刚才自己操作对应的日志条目吗评估日志质量日志是否结构化如JSON格式便于解析是否记录了足够的上下文来追溯一次完整的攻击会话对于登录失败是否记录了尝试的用户名这有助于发现针对特定用户的攻击对于恶意输入是否记录了触发验证失败的输入样本脱敏后实操心得一个优秀的攻击者会尽量让自己的行为看起来“正常”比如使用低频率的请求、模仿真实用户的行为序列。因此日志不仅要记录“明显”的恶意请求更要能通过关联分析发现异常模式。例如同一个IP在短时间内使用了大量不同的用户名尝试登录一个用户会话在短时间内从地理位置上相距甚远的两个IP发起请求等。5.3 修复方案构建可审计、可告警的日志体系日志不是简单的console.log而是一个系统工程。1. 定义并记录关键安全事件在你的应用代码中明确需要记录的安全事件清单认证事件成功/失败登录、登出、密码重置请求/成功、多因素认证触发。访问控制事件访问被拒403、尝试访问未授权资源IDOR尝试、角色提升操作。输入验证事件请求因输入验证如SQLi、XSS过滤被拦截。业务关键操作数据创建、读取敏感数据、更新、删除尤其是批量删除、金融交易、配置更改。系统事件应用启动/关闭、健康检查失败、依赖服务连接异常。2. 采用结构化日志使用JSON格式记录日志确保每个日志条目都包含固定且丰富的字段。const winston require(winston); const logger winston.createLogger({ format: winston.format.json(), transports: [new winston.transports.File({ filename: security.log })] }); // 记录一次失败登录 logger.warn(Login failed, { timestamp: new Date().toISOString(), event: AUTH_FAILURE, userId: null, // 尝试登录的用户名注意隐私可哈希处理 sourceIp: req.ip, userAgent: req.get(User-Agent), reason: Invalid credentials, requestPath: req.path });3. 确保日志包含足够上下文请求标识为每个请求生成一个唯一的requestId并将其贯穿记录在本次请求相关的所有日志中便于追踪。用户标识无论是认证用户还是匿名用户都应有一个标识符如userId,sessionId。操作对象记录被操作资源的ID或类型。操作结果成功或失败以及失败原因。4. 集中化管理与实时监控使用如ELK Stack、Loki、Splunk等工具收集所有服务器、应用、网络的日志。建立看板可视化关键指标如每分钟登录失败次数、异常地理位置登录。设置告警规则这是将被动日志变为主动防御的关键。例如同一IP在5分钟内登录失败超过10次 - 触发IP临时封禁告警。单个用户账户在1小时内从3个不同国家登录 - 触发账户异常告警。检测到特定的攻击载荷模式如union select出现在请求参数中 - 触发Web攻击告警。定期进行日志审计检查是否有告警规则未能覆盖的攻击模式。5. 平衡安全与隐私记录用户名等敏感信息时考虑进行哈希处理使用固定的盐值这样可以在不暴露真实数据的前提下依然能对同一用户的多次事件进行关联分析。完善的日志监控体系就像是应用的“黑匣子”和“警报器”它能让你在攻击发生时就有所察觉甚至在攻击成功前进行阻断并为事后溯源和责任认定提供铁证。6. 漏洞五依赖组件中的已知漏洞6.1 漏洞原理你的应用安全取决于最脆弱的一环现代软件开发高度依赖开源第三方库和框架。这极大地提升了开发效率但也引入了一个巨大的风险你应用的安全性不再仅仅取决于你自己的代码还取决于你所有直接和间接依赖的成千上万个开源组件的安全性。一个你从未直接调用、但被深层依赖的库里的一个高危漏洞就可能成为攻击者打入你系统的突破口。这个漏洞容易被忽略是因为不可见性开发者通常只关注自己直接引用的几个主要库对庞大的传递性依赖树缺乏感知。维护滞后项目启动时引用了当时最新的、安全的库版本但后续没有持续更新。几个月或几年后这些依赖中可能已经爆出了多个严重漏洞。修复复杂性升级一个底层依赖可能会引起一系列不兼容的连锁反应导致修复成本高昂从而产生“拖延症”。OWASP Top 10 中专门有一项是“使用含有已知漏洞的组件”。Juice Shop本身作为一个演示项目其package.json中可能故意引入了一些含有已知漏洞的旧版本库来模拟这种风险。6.2 Juice Shop实战复现扫描你的“供应链”风险我们可以使用自动化工具来快速评估Juice Shop或任何Node.js项目的依赖风险。使用npm audit# 进入Juice Shop项目根目录 cd owasp-juice-shop npm audit这个命令会分析package-lock.json并与漏洞数据库对比列出所有存在已知安全漏洞的依赖并给出严重等级和修复建议通常是升级到某个版本。使用专业SCA工具npm audit是基础的更全面的可以使用像Snyk或OWASP Dependency-Check这样的软件成分分析工具。# 使用Snyk需要先安装并认证 npx snyk testSnyk会提供更详细的漏洞描述、利用路径如何从你的代码触发该漏洞、修复PR链接甚至可以在CI/CD中集成自动修复。手动检查 查看package.json特别关注以下类型的库它们通常是安全重灾区模板引擎如ejs,pug,handlebars可能存在服务端模板注入。序列化/反序列化库如node-serialize,serialize-javascript可能导致远程代码执行。XML解析器如libxml,xml2js可能存在XXE漏洞。命令行工具/子进程库如exec,child_process如果参数用户可控可能导致命令注入。实操心得不要只运行一次扫描就完事。依赖漏洞是动态的新的漏洞每天都在被披露。一个今天安全的版本明天可能就因为一个新发现的CVE而变得危险。因此依赖安全扫描必须是一个持续性的、自动化的工作。6.3 修复方案建立持续的依赖安全管理流程修复已知漏洞最直接的方法是升级到安全版本。但如何系统化地管理这项工作1. 自动化漏洞扫描与告警集成到CI/CD流水线在每次代码推送或合并请求时自动运行npm audit --audit-levelhigh或Snyk test。如果发现中高危漏洞则中断构建强制开发者先解决依赖安全问题。使用依赖管理机器人如GitHub的Dependabot或GitLab的Dependency Scanning。它们会自动监控项目依赖当有新的安全更新或版本发布时自动创建Pull Request更新package.json和锁文件。2. 制定清晰的依赖更新策略语义化版本更新对于package.json中的版本范围指定避免使用过于宽泛的*或x.x.x。使用^允许更新次要版本和补丁版本通常是一个平衡安全与稳定性的选择。定期更新设立“依赖卫生日”比如每月一次专门处理依赖更新。优先处理有安全漏洞的更新再处理功能性更新。锁文件是关键务必提交package-lock.json或yarn.lock到版本库。这确保了所有开发者和生产环境安装的依赖树完全一致避免了“在我机器上是好的”这类问题。3. 升级与测试阅读变更日志在升级前务必查看新版本的变更日志了解是否有破坏性变更Breaking Changes。充分的测试依赖升级后必须运行完整的单元测试、集成测试和回归测试。自动化测试覆盖率越高升级的信心就越足。分层升级如果一次性升级所有依赖风险太大可以制定计划分批次、按模块进行升级。4. 缓解与应急如果暂时无法升级例如修复版本尚未发布或升级会导致不可接受的重构工作量可以考虑临时缓解措施配置安全策略有些漏洞可以通过修改配置来缓解。例如一个库的默认配置不安全但提供了安全选项。使用WAF规则对于已知的、有特定攻击模式的漏洞如某些反序列化漏洞可以在Web应用防火墙层面添加规则进行拦截。代码层隔离如果漏洞存在于一个非核心的、功能独立的库中可以考虑将其替换为其他更安全的库或者将其功能隔离在一个低权限的沙箱环境中运行。5. 选择与评估依赖在引入新依赖时进行评估检查其维护活跃度最近提交、Issue处理速度、流行度、已知漏洞历史。最小化依赖定期审查package.json移除不再使用的依赖。依赖越少攻击面就越小。管理依赖安全本质上是管理软件的“供应链安全”。它要求开发者从被动的“漏洞响应”转向主动的“风险管控”将安全作为软件生命周期中一个持续进行的环节。