.NET APIs: 7 security flaws we still see in 2026 (and how to fix them)
APIs don't go down because of genius hackers.
They go down because of a debug endpoint left in production, a token sitting in the logs, a NuGet package that hasn't been updated in 8 months.
Details. Except an API exposed on the internet gets scanned by bots within minutes. And bots love details.
Quick reminder before we start: OWASP (the Open Worldwide Application Security Project) publishes the list of the most widespread flaws. Their API Security Top 10 is the reference on the subject.
1. Authenticated ≠ authorized
GET /api/orders/42. The token is valid, so we return the order. But nobody checked that it actually belongs to this user. It has been OWASP's #1 flaw for years (the infamous BOLA, Broken Object Level Authorization) and it's the one I run into most.
The fix: check that the caller is allowed to access this resource, not just this endpoint.
2. Secrets in appsettings.json
A connection string or an API key committed to Git, it happens in every team. And bots scan GitHub for exactly that, around the clock.
The fix: User Secrets locally, Key Vault in production. Never version a secret. (Private repo on Azure DevOps? It lowers the risk, but everyone has access to the history.)
3. Over-posting on your EF Core entities
Binding the User entity directly in your endpoint, without a DTO? A client adds "IsAdmin": true to the payload and becomes an admin. I've seen it happen, it's surprising.
The fix: one clean DTO per endpoint in your application layer. Your EF entities never leave the backend.
4. Swagger open in production
Convenient for you, even more so for an attacker: your entire API documentation served on a platter. And careful, an exposed staging environment counts too.
The fix: personally, I keep Swagger local only. And for partners, I share just the endpoints they need, not the whole surface.
5. The stack trace that tells everything
One unhandled exception, and the client receives your namespaces, your internal structure, sometimes your SQL query.
The fix: an exception middleware with ProblemDetails. Clean error for the client, full details in your logs.
6. Zero rate limiting on the login
A /login with no limit is self-service brute force.
The fix: the middleware has been built into .NET since .NET 7. A few lines, zero dependencies.
7. Unreviewed AI code
The 2026 flaw. Your AI produces an auth layer that compiles and works. But it validates the JWT issuer poorly, or skips an edge case.
The fix: generated code goes through review like everything else. Especially auth and input validation.
Audit bonus: the man-in-the-middle test
When I audit a project, I put myself in a man-in-the-middle position with Charles Proxy.
In one direction, I tamper with the front end's calls: I change ids to try to reach another user's data (flaw #1), for instance. In the other direction, I tamper with the back end's responses before they're displayed, flipping an "IsAdmin": false to true, to see whether I can open the admin UI and try calls behind it.
You'd be surprised how many APIs swallow whatever the front end sends them. Zero server-side checks, and then anything becomes possible.
None of these flaws takes more than an hour to fix. And each of them can cost you dearly in production.