按框架
ASP.NET Core 安全 — 生产环境错误、密钥与授权
ASP.NET Core 很稳固，但事故来自配置：生产环境暴露详细错误、密钥硬编码在 appsettings、以及缺失 [Authorize]。隐藏生产环境错误、从配置之外加载密钥、显式做授权。以防御视角讲解，不含攻击步骤。
面向：在 ASP.NET Core 上运营应用或 API 的人。这里不讲攻击步骤——只讲如何让稳固的地基持续生效，同时堵住配置开出的缺口。要看全局，请参阅 按框架的安全防护入口。
三大陷阱（都出在配置里）
ASP.NET Core 的机制很出色，但下面这三项要由你在配置和代码中守护。
① 生产环境的详细错误
Developer Exception Page 等泄露内部信息。可被故意触发错误提取出来。
② appsettings 里的密钥
连接字符串/密钥硬编码。经由误提交或暴露而泄露。
③ 缺失 [Authorize]
忘了加，任何人都能访问。也没有所有者检查。
此外还要留意：不安全的反序列化（BinaryFormatter 等）、模型绑定中的 over-posting、以及未打补丁的 NuGet 依赖 CVE。
如何堵住这些缺口（3 步）
生产环境隐藏详细错误
从配置之外加载密钥
让授权显式化并切断危险的输入路径
[Authorize] 和所有者检查（默认倾向拒绝）。用 DTO 或 [Bind] 限制 over-posting，并不要用不安全的格式反序列化不受信任的数据。让 NuGet 依赖保持 CVE 监控 + 快速打补丁（→ IDOR 是什么）。常见（危险）
- 生产环境暴露 Developer Exception Page
- 密钥硬编码在
appsettings.json里 - 忘了加
[Authorize]，也没有所有者检查 - 模型接受所有字段（over-posting）
正确
- 生产环境隐藏详细错误
- 密钥来自 User Secrets/环境变量/Key Vault
- 显式的授权（默认拒绝、所有者检查）
- 用 DTO/[Bind] 限制绑定
本站的视角：即便地基稳固，配置和授权仍归你自己
ASP.NET Core 在认证、授权和数据保护方面机制稳固，但生产环境配置和把授权落地，是你必须按每个环境、每个端点做对的东西。本站是另一套技术栈，但原则是一样的：生产环境不泄露内部信息、密钥放在配置之外、在所有对外入口都写好授权、并监控依赖的 CVE。稳固的地基，只有配上正确的配置和显式的授权才能兑现价值。
接下来读
- 入口：按框架的安全防护 · Spring Boot 安全（同为企业级，依赖/授权形态相似）
- 密钥：不把密钥放进公开目录 · 实操：漏洞应对实务
- 术语：IDOR 是什么 · RCE 是什么
FAQ
QASP.NET Core 安全吗？
ASP.NET Core 是成熟稳固的地基，在认证、授权和 Data Protection 方面都有强大的机制。用得对它很强大，但事故不是来自核心，而是来自配置。在生产环境暴露详细错误、把密钥硬编码在 appsettings、以及忘记加授权特性，与其说是框架特有的问题，不如说更多是配置/运营层面的问题。
Q密钥（连接字符串、API 密钥）应该放在哪里？
规则是：不要硬编码在 appsettings.json 里。开发环境用 User Secrets；生产环境从环境变量或云端密钥管理器（如 Key Vault）加载。appsettings.json 很容易最终进入仓库，并经由公开目录或误提交而泄露。一旦泄露，请立即轮换连接字符串或密钥。
Q如何防止忘记加授权特性？
在控制器或端点上忘了加 [Authorize]，任何人都能未经认证就访问它。把默认倾向设为『拒绝』（用回退策略拒绝未认证的请求），用基于角色/策略的授权把权限写明确，并编写资源所有者检查。不要止步于“已登录＝允许”——还要验证目标对象的所有者。