I have very specific view that ASP.NET Core security is probably fine, but overall industry guidelines are meh and tailored for security people. Almost all issues which I have with implementing security was due to other external factors, like:
- lack of resources
- Lack of training in securing solution
- Lack of time to find proper solution
- Lots of jargonism and abstractiosn in describing security.
My observvations applied to cases where solo-developer or team of developers responsible for implementing security for their "product". That can be devs in small, mid sized org, or teams in large orgs where security department demands some techniquest to be employed. Or even better goverment agencies which everywhere in the world underfunded and do not have enough resources for securing things.
I would start with stories which I experience. They are not pretty, and disfunctional I would say.
One customer of mine ask me develop small web application which works on HIPAA data. And one of request for security was to encrypt ID displayed on the URL and in the HTML. I implement this transparently using DataProtection API in ASP.NET core, but to this day, I do not know if this is correct approach. Even if solution is passed audit, that's not refreshing.
Same customer as in Story 1 develop database by themself. Login and Hashed password on the database. All password validation, password reset and password recovery via stored procedures which does not map well with Identity stores concept. I manage to override methods on UserManager and I hope that this allow me not re-implement all other cookie-based authentication, so I hope that I dodge the bullet and did not screwup anything in major way.
Other customer of mine working on startup in betting domain. We develop kiosk solution where console app inside kiosk control printer and cash dispenser. That console app talks with remote server to record transaction. Initially we go with client credentials and register device on app start. That's less then ideal solution, which I latest plan to replace with device registration flow similar to that one which performed by GitHub CLI for example. I barely understand what risks I left in the currently implemented solution. Also this B2B domain where your final solution would be relying on the auth data provided by the partner company. Also if you have money, you treated like a king and everybody likes you, if you small fish trying to enter domain nobody talk with you.
Being on the receiving end of payment gateways, integration with these custom made solution is a pain. They seems to be always implement their own solution with sometimes variants of HMAC. They document bare minimum to say, that API is documented. Overall very often solution looks shoddy, and because you implement their flow you alwayas question is that part secured enough? What potential risks laying there?
Construction startup which provide reporting and live data for some construction equipment. Pressure to deliever was high, and understanding security was non-existing. All construction companies with whom startup was try to work, all can give you wealth of data. There supposedly processes, but they was used mostly to cover operational issues and money loss due to that. How will you choose security solution for your case properly? Selected solution should be non-invasive, otherwise people will ignore that solution.
All these stories share one common thing - mismanagement. Obviously that's not a problem with security, but that's typical situation which affects security. Problems with security will be magnified under mismanagement. Mostly bad management either put a pressure, so you have no time to properly learn security, or would pretend that somehow security is solved problem and developers just do not do their job.
Currently ASP.NET provide sea of options how to implement security for yourself. But as matter of fact, most developers do not know security well, so they need guidance. So somehow I would like some guidance how to preselect security options for some systems. Preferable closer to specific domain and be specific. It is easier to translate explicit solution for your domain, then try to derive solution from abstract definitions.
About language in which docs written about security. My opinion that text use overly abstract terms for most software developers.
For example Principal and Identity. I understand that difference is important, but for most small and mid business these concepts likely would be blended into single concept. Even in large organizations not sure that this distionction executed very often.
Scopes are such nice concept in OIDC and if you implement Identity Server you will have fun trying to wrap why do you need scope, client and API resource. Identity Server is just example which I'm most familiar with. This language comes from OAuth docs, and nowadays more or less explained in Duende docs, much better then in Identity Server3 days admittedly. In ASP.NET core docs there separation in tutorials how to configure some identity provider and how to configure Identity Server (for example). If you unlucky and decide that you need your own identity provider (even if for integration testing purposes only) due to lack of understanding these lines blur and you start confusing things here and there. And because Identity Server has security defaults which do not log anything at about reasons of failures you have to guess what you do wrong. That's not ASP.NET issue per se, but educational and related specifically to Identity Server. Still that's so much process, that in our team we was joking that configuring Identity Server is initiation process for any software developer.
In order to learn how to implement security solution you usualy read all articles on the matter, even if sometimes they are from different language. That usually helps at least understand top-level concepts and then you go on second route of learning trying to apply what you learn in C# and ASP.NET.
I would be happy if docs on general concepts would be less intimidating. I read them to understand how security works, when all other troubleshooting options fails. That hint on the lack of content mostly. I do not know what's missing, but something definitely missing. Proper ORM mapping also not trivial concept, but somehow they are managed to be presented in simple way where you can safely learn things step by step.
Flows and configuration. If implementing different flows, usually list of requied and options parameters scattered across docs and you have to check if what's written applied to specific flow, or more importantly what's completely irrelevant. Thats draining.
Obviously some of the issues which I have with security is my personal lack of understanding how security works. Some of the issues which I have with security definitely was bad customer selection.
Independently how much efforts do you put in security web application, you always understand that something you do not implement, and because you not really security guy, you cannot assess is this even a risk for you? Maybe we as developers need just guidance how to make not secure application, but just trustable application, so if money on security was not allocated, as professional you know that you do as much as you can.
What I think is needed is what I can call "Applied Security" where "regular" developer can be taught limited security techniques which allow provide "good enough" security. Maybe I just want much better teaching pipeline for Security.