dependency management
该标签下有 4 篇文章
Express（Node.js）安全 — 守护要靠你自己添加
Express 是极简框架——默认几乎不内置任何安全功能，因此守护是由开发者自己添加的。要点：(1) 安全响应头（helmet 类）；(2) 输入的校验与净化；(3) 以所有者为范围的授权，而不只是认证；(4) 限流（暴力破解 / DoS）；(5) 依赖（npm）CVE 监控与快速打补丁。此外，对外部 URL 请求做 SSRF 防护，密钥放进环境变量、不混入代码。极简框架带来自由，同时也把防御的责任交给了你。
Next.js 安全防护 — Server Actions、环境变量与依赖 CVE 的守护方法
Next.js 默认值偏安全，但事故发生在『服务端/客户端的边界』。三大问题：(1) 环境变量泄露（误用 NEXT_PUBLIC_ 或把服务端专用密钥传给客户端）、(2) Server Actions / Route Handlers 缺失授权（有认证但没有所有者范围）、(3) 依赖包的已知 CVE（含框架核心 RCE，按实际运行版本判定并快速打补丁）。防御：密钥限定在服务端、留意边界、每个 action 都做授权、用机器监控依赖 CVE。
Ruby on Rails 安全 — Strong Parameters、授权与 gem 的 CVE
Rails 自带约定和安全默认值（CSRF 防护、Strong Parameters、ORM），用得对就很稳固。但事故来自运营。三大问题：(1) 过于宽松的 Strong Parameters 导致 Mass Assignment（覆写 is_admin 等）；(2) 单薄的授权（登录＝认证，但没有所有者范围）；(3) 已知的 gem（依赖）CVE。此外还有在 where 中用字符串拼接导致的 SQLi、危险的动态方法（send/constantize）、以及泄露的 credentials/secret_key_base。防御：收紧 permit、让授权显式化、监控 gem 的 CVE。
Spring Boot 安全防护 — 依赖 CVE、Actuator 暴露与授权的守护方法
Spring（Spring Boot）是企业级常青栈。事故类型：(1) 依赖包的已知 CVE（如 Log4Shell 这类被广泛继承的地基缺陷，按实际运行版本判定并快速打补丁）、(2) Actuator 等管理/诊断端点暴露（信息泄露/被操作）、(3) Spring Security 授权设置缺失（有认证但权限检查薄弱）、(4) 不安全的反序列化。防御：用机器监控依赖 CVE 并快速打补丁、收紧 Actuator/管理面、显式授权、不反序列化不可信数据。