按框架的安全防护

WordPress 拥有最大份额，因此在统计上是最大的目标。入口与其说是核心，不如说是插件/主题漏洞、疏于更新、弱/复用的管理员，以及暴露的管理面（wp-admin/xmlrpc/REST 枚举）。防御：自动化核心+插件更新、删除不用的插件/主题、给管理员配强密码+2FA、限制管理面暴露与登录尝试、篡改检测加离线备份。

Laravel 默认值相当安全，但事故大多来自运营。三大陷阱：(1) .env 或密钥文件从公开目录可通过 URL 读取；(2) 生产环境 APP_DEBUG=true，把环境变量与连接信息暴露在错误页上；(3) 缺失授权（有登录＝认证，但没有按所有者划分的授权 / Mass Assignment 覆盖了预期外的字段）。防御：密钥放到 public 之外并设权限 600、生产环境关调试 + 配置缓存、用 Policy/Gate 做授权、声明 $fillable。

Next.js 默认值偏安全，但事故发生在『服务端/客户端的边界』。三大问题：(1) 环境变量泄露（误用 NEXT_PUBLIC_ 或把服务端专用密钥传给客户端）、(2) Server Actions / Route Handlers 缺失授权（有认证但没有所有者范围）、(3) 依赖包的已知 CVE（含框架核心 RCE，按实际运行版本判定并快速打补丁）。防御：密钥限定在服务端、留意边界、每个 action 都做授权、用机器监控依赖 CVE。

Express 是极简框架——默认几乎不内置任何安全功能，因此守护是由开发者自己添加的。要点：(1) 安全响应头（helmet 类）；(2) 输入的校验与净化；(3) 以所有者为范围的授权，而不只是认证；(4) 限流（暴力破解 / DoS）；(5) 依赖（npm）CVE 监控与快速打补丁。此外，对外部 URL 请求做 SSRF 防护，密钥放进环境变量、不混入代码。极简框架带来自由，同时也把防御的责任交给了你。

Spring（Spring Boot）是企业级常青栈。事故类型：(1) 依赖包的已知 CVE（如 Log4Shell 这类被广泛继承的地基缺陷，按实际运行版本判定并快速打补丁）、(2) Actuator 等管理/诊断端点暴露（信息泄露/被操作）、(3) Spring Security 授权设置缺失（有认证但权限检查薄弱）、(4) 不安全的反序列化。防御：用机器监控依赖 CVE 并快速打补丁、收紧 Actuator/管理面、显式授权、不反序列化不可信数据。

Django 是『开箱即用』且默认值稳固（ORM、CSRF、模板自动转义、认证），配置得当就很稳固。但事故来自配置。三大问题：(1) 生产环境 DEBUG=True，在错误页上暴露配置、环境变量和密钥；(2) SECRET_KEY 泄露（签名/会话的根基）；(3) 单薄的授权（缺失 is_staff/权限检查）。此外还有通过 raw()/extra() 或字符串拼接导致的 SQLi、不安全的反序列化（pickle）、未设置的 ALLOWED_HOSTS、以及依赖（pip）CVE。防御：生产环境 DEBUG=False、SECRET_KEY 从环境变量加载、显式授权。

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。

ASP.NET Core 是成熟稳固的地基，但事故来自配置。三大问题：(1) 在生产环境暴露详细错误 / Developer Exception Page（内部信息泄露）；(2) 密钥硬编码在 appsettings.json 里（应改用 User Secrets / 环境变量 / Key Vault）；(3) 缺失授权特性（[Authorize]）。此外还有不安全的反序列化（BinaryFormatter 等）、模型绑定中的 over-posting（用 DTO/[Bind] 限制）、以及 NuGet 依赖 CVE。防御：生产环境隐藏详细错误、从配置之外加载密钥、让授权显式化。