Say I have an MVC .net core website where 100% of the controllers/methods are behind [Authorize] attributes (complete with policies and all). Would it be taboo, to carve out a set of un-authorized/anonymous controller/methods to handle user requests for access to the site. It seems perfectly reasonable to me, and outside of developer error, I can't see it introducing a new security risk.
1 Answer
No problem at all, in fact i would suggest approaching the problem the other way round. Authenticate all your actions by default, and use AllowAnonymous to permit access to your public actions. If you're worried about missing some you can use unit tests or static analysis to flag up unprotected actions.
-
If you require
Authorizeat the class level, you don't have to addAuthorizeto each action. Just the ones you want to override (i.e.AllowAnonumousCommented Feb 13, 2018 at 14:54 -
Right on richzilla. That's the approach I'm already using. It just wanted to know if it introduced any vulnerabilities that otherwise wouldn't be there. As the access request portion is actually a separate site at the moment, that I don't want to maintain. I want to bring it in to the existing site, but wanted to have solid ground to stand on when I say that it's not introducing new vulnerabilities foundationally. See, I have to explain the work to non-development staff. Thanks I'm marking this as the answer, unless someone offers a valid dispute. Commented Feb 14, 2018 at 1:24