“Laravel 安全”“WordPress 加固”——我们检索时，往往是“按所用技术”去找答案。本页是通往按框架防护的入口（不含攻击步骤）。
共通（每种框架都一样）
访问控制、密钥管理、注入、依赖 CVE、配置错误。基础的防御措施也是共通的。
框架特有（各章节讲解）
「危险的默认配置」和「在该技术上最常被瞄准的位置」。因技术而异的只有这里。
所有框架共通的弱点类型
先看全局。以下这些类型不分技术、被反复攻击；各框架章节会说明它们在该技术上以什么形式出现。
按框架划分的指南
请阅读你所用技术栈的章节。每章都按“默认危险 → 最常被瞄准的位置 → 加固步骤”的顺序展开。
WordPress
Laravel
Next.js
Java / Spring
其他框架
生产环境要先检查的设置（按框架速查表）
无论哪种框架，都要先检查两件事：生产环境是否会显示详细错误，以及密钥放在哪里。各框架的设置名称不同，请在下表中找到自己那一行。设置名称已对照各项目当前的官方文档核实（版本见最后一列）。
| 框架 | 关闭详细错误页面 | 密钥放在哪里，以及要注意的地方 | 容易漏掉的设置 | 核实的文档 |
|---|---|---|---|---|
| WordPress | 在 wp-config.php 中把 WP_DEBUG 设为 false（默认即为 false） | 数据库凭据在 wp-config.php 中；不要在公开目录里留下副本 | 用 DISALLOW_FILE_EDIT 禁止从后台编辑文件；删除不用的插件 | Advanced Administration Handbook |
| Laravel | 在 .env 中设置 APP_DEBUG=false | 绝不提交 .env（加密后的 .env.encrypted 可以） | 执行 config:cache 后，配置文件之外的 env() 不再返回值 | 13.x |
| Next.js | 先 next build 再 next start 运行；绝不暴露开发服务器 | NEXT_PUBLIC_ 变量会被内联到浏览器端的 JavaScript 中 | 给秘密信息加上了 NEXT_PUBLIC_ 前缀 | 16.x |
| Spring Boot | 不让堆栈跟踪出现在错误响应中（保持默认） | 通过环境变量传入，不要硬编码在配置里 | Actuator 默认只通过 HTTP 暴露 health；绝不要设置 management.endpoints.web.exposure.include=* | 4.1 |
| Django | DEBUG = False | 从环境变量或文件读取 SECRET_KEY，不放进源代码管理 | 设置 ALLOWED_HOSTS；运行 manage.py check --deploy | 6.1 |
| Ruby on Rails | 使用生产环境配置（config/environments/production.rb） | config/credentials.yml.enc 加 config/master.key；绝不提交 master.key | 用 config.force_ssl = true 强制 HTTPS | 8.1 |
| Express | NODE_ENV=production 会去掉默认错误响应中的堆栈跟踪 | 通过环境变量传入，不写在代码里 | 用 helmet 设置安全响应头；app.disable('x-powered-by') | 当前官方指南 |
| ASP.NET Core | 开发者异常页面只在 Development 环境中开启（当前模板的默认设置） | 用户机密（user secrets）只用于开发；生产环境用环境变量或密钥保管库 | 绝不要在 ASPNETCORE_ENVIRONMENT 为 Development 的状态下运行生产环境 | 10.0 |
真实案例：多数事故来自没打的更新和生产环境设置，而不是核心 bug
突出的模式不是框架本身的缺陷，而是有修复却没有应用，或者开发用的设置被留在了生产环境。
- Equifax（2017 年）：Apache Struts 漏洞（CVE-2017-5638）的修复在公开当天就已发布，但没有应用到一个对外系统上，约 1.47 亿人的个人信息因此泄露（→ Equifax 数据泄露事件）。
- Log4Shell（2021 年）：Java 日志库中的漏洞。许多组织是通过其他组件间接引入了它，连自己有没有在用都无法判断（→ Log4Shell）。
- AI 代理案例（2026 年）：研究用的 AI 代理访问真实网站时，从暴露的调试页面读取到了凭据，而这些网站并没有察觉（→ AI 代理访问真实网站，英文）。
在 OWASP Top 10（2025）中，第 1 位是失效的访问控制，第 2 位是安全配置错误，第 3 位是软件供应链失效（你所依赖的组件出问题）。这些在任何框架上都会发生。
如何检查自己的网站
以下检查只在你自己管理的网站上进行。
打开一个不存在的 URL，看错误页面
使用框架自带的检查命令
python manage.py check --deploy；Laravel 可以用 php artisan about --only=environment 查看调试模式。Spring Boot 请检查配置中的 management.endpoints.web.exposure.include。常见错误与对策
| 常见错误 | 会发生什么 | 对策 |
|---|---|---|
给秘密 API 密钥加上 NEXT_PUBLIC_ 前缀 | 密钥被内联到浏览器端 JavaScript 中，任何人都能读取 | 去掉前缀，只在服务端使用，并在签发方作废已泄露的密钥 |
| 暴露所有监控端点（例如 Spring Boot Actuator） | 配置值和内存内容可能从外部被读取 | 只暴露 health 等必要的端点，其余放在认证之后 |
| 停用了不用的插件，但没有删除 | 文件仍留在服务器上，而且不再收到更新 | 不用的就删除 |
| 看到了更新通知，却没有确认是否已应用 | 明明有修复，漏洞却一直开着（Equifax 的模式） | 更新后确认版本，并定期运行依赖扫描 |
本站的视角：事故来自框架的运营方式，而不是框架本身
争论“这个框架安全/危险”往往帮不上忙。真实的事故大多并非源自核心的 bug，而是来自“用法”——疏于更新、密钥泄露、缺失授权、危险的默认配置。本站自身就运行在 Next.js 上，我们的主要防御并没有什么特别之处：监控依赖的 CVE、不把密钥放进代码和公开目录、强认证、可恢复的备份。每个框架章节，就是把这些基础措施落实到具体技术上。
先做好共通的基础措施
在深入某个框架章节之前，先把在任何技术上都有效的措施做好，效率更高。
- 入门：安全底线清单（管理员账户、密钥、打补丁、检测、恢复）
- 实操：漏洞（CVE）应对实务 · 监控依赖包的 CVE（osv-scanner）
- 密钥：不把密钥放进公开目录
出处
- WordPress Advanced Administration Handbook「Hardening WordPress」「Debugging in WordPress」— developer.wordpress.org
- Laravel 13.x「Configuration」（Environment File Security / Debug Mode）— laravel.com
- Next.js「How to use environment variables in Next.js」（16.x）— nextjs.org
- Spring Boot 4.1「Endpoints」（Actuator 的暴露）— docs.spring.io
- Django 6.1「Deployment checklist」— docs.djangoproject.com
- Ruby on Rails Guides「Securing Rails Applications」（8.1）— guides.rubyonrails.org
- Express「Production Best Practices: Security」「Error Handling」— expressjs.com
- Microsoft Learn「Handle errors in ASP.NET Core」（10.0）— learn.microsoft.com
- OWASP Top 10:2025 — top10.owasp.org
接下来读
- 指南：WordPress 安全 · Laravel 安全
- 基础：安全底线清单（所有框架共通）
- 术语：CVE 是什么（追踪框架已知漏洞的单位）