dotnet-security
.NET application security - the OWASP Top 10, applied
This is the hardening reference: how the 2021 OWASP Top 10 categories show up in an ASP.NET Core service and what to do about each. OWASP's 2025 revision reshuffles the ranks, folds SSRF into A01, and adds software-supply-chain and exceptional-conditions categories; the mitigations map either way (supply chain under A06 / A08, exceptional conditions under A04 / A05 and dotnet-web-error-handling), so the sections keep the stable 2021 numbering. It is a static checklist you read while writing or reviewing code, and it pairs with the security-guidance plugin, which reviews a live diff at runtime - that plugin is the moving part, this is the durable map. Two whole areas are deliberately out of scope and live next door: how you actually wire up sign-in and policies is dotnet-authentication, and which crypto primitive to reach for is dotnet-cryptography. This skill says where those controls belong in the threat model, not how they are built. Floor is .NET 8 / C# 12.
On a .NET Framework 4.8 codebase the TLS defaults, BinaryFormatter (still shipping there), classic-ASP.NET security headers, and the dependency-audit prerequisites differ - those deltas are in references/net-framework-48.md.
The principle under all of it: treat every byte that crossed a trust boundary as hostile until you have validated it, and make the secure path the default one - a control you have to remember to add is a control you will eventually forget.
A01 - Broken access control
The most common real-world failure: the user is authenticated, but the app never checks whether this user may touch this thing.
- Default-deny. Set a fallback authorization policy so that an endpoint with no explicit policy is still protected, not open. Forgetting an
[Authorize]then fails closed instead of leaking the route. Anonymous endpoints opt out loudly withAllowAnonymous.