Recently my team upgraded to .NET Core 2.2. We have an API that needs to be accessed from an Angular project living in a different domain, so we had CORS enabled this way:
Disclaimer: this is an intranet application – so it is only accessible inside of a corporate firewall, making it more acceptable to AllowAnyOrigin. If you have an externally available website, allowing any origin will make you vulnerable to cross-site scripting attacks, so, probably don’t do it.
ASP .NET Core 2.2
In 2.2, the ASP.NET Core team addressed a security issue related to CORS when AllowAnyOrigin (which is the same as WithOrigins(*)) is set along with AllowCredentials(). You can read a lot more about the security issue in this blog post and on the AspNetCore’s GitHub issues page, but the team decided that it would be best to break this functionality to prevent people from mis-configuring CORS and opening themselves up for attack.
The official migration documentation for 2.2 says that you either:
- Remove AllowCredentials()
- Explicitly list allowed Origins (do not use AllowAnyOrigin)
Making it work again
Following the migration documentation, you can fix it by explicitly setting up which origins have access. In the case of my team, the problem was most visible during development where two different websites (running on different localhost ports) needed to communicate with each other. So, the fix is to add the origin to the list of allowed origins in the CORS policy:
Note that an origin consists of three parts:
And note that there is not an ending slash.