面向：在 ASP.NET Core 上运营应用或 API 的人。这里不讲攻击步骤——这是一份用于加固的实务参考：优先级排序的清单、分领域指引、以及自查。要看跨框架的全局，请参阅 按框架的安全防护入口。
优先级排序的加固清单
按此表自上而下执行。P0 是前提，P1 是最频繁的事故来源，P2 是持续的日常维护。
P0 ── 前提（先做这个）
生产环境不显示详细错误 / 把密钥外置 / 快速为 NuGet 依赖 CVE 打补丁
P1 ── 最主要的事故来源
授权（[Authorize]、默认拒绝、所有者）/ over-posting 防御（DTO/[Bind]）
P2 ── 日常维护
不安全的反序列化 / HTTPS、响应头、antiforgery / SSRF
| 优先级 | 控制项 | 具体做法（ASP.NET Core） |
|---|---|---|
| P0 | 生产环境错误 | UseExceptionHandler。生产环境不显示 Developer Exception Page/详情（正确的环境判断） |
| P0 | 密钥外置 | 不要硬编码在 appsettings.json。开发 = User Secrets，生产 = 环境变量/Key Vault |
| P0 | NuGet 依赖 CVE | 用 dotnet list package --vulnerable/osv-scanner 监控；以运行中的版本判定，快速打补丁 |
| P1 | 显式授权 | [Authorize] + 默认拒绝（回退策略）+ 基于资源/所有者的检查 |
| P1 | over-posting 防御 | 绑定到 DTO，而非直接绑定实体。用 [Bind] 限制接受的字段 |
| P2 | 反序列化 | 不要用 BinaryFormatter。不要用不安全的格式还原不受信任的数据 |
| P2 | HTTPS/响应头/CSRF | UseHttpsRedirection、UseHsts、antiforgery（CSRF）、Cookie 属性 |
| P2 | SSRF | 服务端取回用允许列表 + 阻断内部 IP/元数据 |
1. 生产环境错误暴露（P0）
- 在生产环境，通过
UseExceptionHandler切换到通用的错误页，并不显示 Developer Exception Page/详情（把环境判断做对，例如ASPNETCORE_ENVIRONMENT=Production）。 - 不要把堆栈跟踪或内部结构泄露到外部。
2. 把密钥外置（P0）
- **不要把连接字符串或密钥硬编码在 appsettings.json 里。**开发环境用 User Secrets，生产环境用环境变量或云端密钥管理器（Key Vault）。
- appsettings.json 容易经由误提交或暴露而泄露。不要把它提交到仓库，也不要放进公开目录（→ 不要把密钥放进公开目录）。泄露时及时轮换。
3. NuGet 依赖 CVE（P0）
- 用
dotnet list package --vulnerable或 osv-scanner 机器监控已知 CVE，以运行中的版本判定，并快速打补丁（→ 监控依赖包的 CVE · 漏洞应对实务）。 - 让 .NET 保持在受支持的版本，不要放着 EOL 版本不管。
4. 授权（P1 — 最主要的来源）
常见（危险）
- 在端点上忘了加
[Authorize] - 已认证，但没有所有者检查
- 默认倾向“允许”，未认证的请求也能通过
- 没有角色/策略设计，检查零零散散
正确
[Authorize]+ 通过回退策略实现默认拒绝- 基于角色/策略 + 基于资源的授权以确认所有权
- 在每一条读取/更新/删除路径上核验
- 授权显式构建，不交给默认值
参阅 IDOR 是什么。认证和授权是两回事；在靠近数据的地方做授权。
5. over-posting（P1）
- **不要直接绑定实体。**绑定到一个仅供输入的 DTO，只接受你需要的字段。
- 或者用
[Bind]显式限制接受的字段。不要让某个权限标志被外部输入覆写。
6. 不安全的反序列化与输入（P2）
- 不要用
BinaryFormatter（过时/不安全）。不要用不安全的格式还原不受信任的数据（在特定条件下可能导致 RCE）（→ RCE 是什么）。 - 在使用前，用**模型校验（data annotations 等）**校验输入的类型/范围/允许值。
7. HTTPS、响应头、antiforgery（P2）
- 用
UseHttpsRedirection+UseHsts强制 HTTPS，并把 Cookie 标记为 secure/httponly/samesite。 - 在表单/会更改状态的请求上使用 antiforgery 令牌（CSRF 防御）（→ CSRF 是什么）。
- 加上安全响应头（用 安全响应头检查器 检查你自己的站点）。
8. SSRF 与服务端取回（P2）
- 服务端（
HttpClient等）取回用户提供的 URL 时，应把目标限制在允许列表，并阻断到内部 IP/元数据的访问（→ SSRF 是什么）。校验上传，并把它们存放在公开面之外。
验证：你的 ASP.NET Core 真的加固了吗
做完不算完——检查过才算完成。以下是针对你自己环境的防御性自查。
1
生产环境没有 Developer Exception Page
在生产环境故意触发一个错误，确认详情（堆栈 / Developer Exception Page）不会对外显示。
2
密钥不在配置/仓库里
确认连接字符串/密钥没有硬编码在
appsettings.json 里，且仓库里没有任何密钥。3
授权是否有效
在测试环境里，请求别的用户的资源，确认被拒绝（读取/更新/删除）。
4
依赖与 HTTPS/响应头
确认
dotnet list package --vulnerable/osv 干净，并通过响应头检查器确认 HTTPS/HSTS 存在。本站的视角：即便框架稳定，配置和授权也是你自己的责任
ASP.NET Core 在认证、授权和 Data Protection 方面机制稳固，但生产环境配置和把授权落地，是你必须按环境、按端点逐一做对的东西。本站是另一套技术栈，但原则是一样的：生产环境不泄露内部信息、把密钥放在配置之外、在所有公开端点都写好授权、并监控依赖的 CVE。框架的安全功能，只有配上正确的配置和显式的授权才能发挥作用。
接下来读
- 入口：按框架的安全防护 · Spring Boot 安全（同为企业级，依赖/授权问题相似）
- 实操：漏洞应对实务 · 监控依赖包的 CVE · 不要把密钥放进公开目录
- 术语：IDOR 是什么 · RCE 是什么 · CSRF · SSRF
- 工具：安全响应头检查器
来源与确认范围
以下原始资料支持上文的配置、影响范围或应对措施，链接于2026年10月23日确认。请核对资料中的版本和配置条件。清单优先级及经验是本站的整理，不代表全文重新核验或安全保证。