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.


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.

| improve this answer | |
  • If you require Authorize at the class level, you don't have to add Authorize to each action. Just the ones you want to override (i.e. AllowAnonumous – Berin Loritsch Feb 13 '18 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. – DiscipleMichael Feb 14 '18 at 1:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.