Introduction

AllowedHosts and UseCors both affect incoming HTTP traffic in ASP.NET Core 3.x, but they solve completely different problems. AllowedHosts is about which Host headers your server will accept, while CORS is about which browser origins are allowed to read responses from your API.

If you treat them as interchangeable, the configuration becomes confusing very quickly. The easiest way to understand the difference is to look at the HTTP headers each one cares about and the layer where it applies.

What AllowedHosts Does

AllowedHosts is configured in appsettings.json and is used to restrict valid request host names. Its main job is to reduce exposure to host-header based misrouting or host-header injection issues.

A typical configuration looks like this:

{
  "AllowedHosts": "api.example.com;localhost"
}

This setting is about the Host header that comes with the request, for example:

Host: api.example.com

If the application receives a request with an unexpected host name, the host filtering behavior can reject it. This matters at the server boundary, regardless of whether the client is a browser, curl, Postman, or another backend service.

What UseCors Does

CORS stands for Cross-Origin Resource Sharing. It is a browser security mechanism, not a host-header filter. When a frontend running at one origin wants to call an API at another origin, the browser checks whether the API allows that cross-origin access.

In ASP.NET Core 3.x, you usually configure a named CORS policy in Startup:

1public void ConfigureServices(IServiceCollection services)
2{
3    services.AddCors(options =>
4    {
5        options.AddPolicy("Frontend", builder =>
6            builder.WithOrigins("https://app.example.com")
7                   .AllowAnyHeader()
8                   .AllowAnyMethod());
9    });
10
11    services.AddControllers();
12}
13
14public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
15{
16    app.UseRouting();
17
18    app.UseCors("Frontend");
19
20    app.UseEndpoints(endpoints =>
21    {
22        endpoints.MapControllers();
23    });
24}

This configuration is about the browser's Origin header and the API's Access-Control-Allow-Origin response header, not the Host header.

The Two Features Protect Different Boundaries

The distinction becomes clearer if you compare their inputs:

• 'AllowedHosts checks the host name being used to reach your server'
• CORS checks which browser origin is trying to read the response

That means:

• 'AllowedHosts applies to all clients'
• CORS is mainly enforced by browsers

If Postman can call your API but browser JavaScript cannot, that points to CORS, not AllowedHosts. If the request is reaching the wrong host name or being rejected because the host header is unexpected, that points to AllowedHosts, not CORS.

A Simple Mental Example

Suppose your API is hosted at https://api.example.com, and your frontend runs at https://app.example.com.

The request might look like this:

• 'Host header is api.example.com'
• 'Origin header is https://app.example.com'

From the server's perspective:

• 'AllowedHosts decides whether api.example.com is an allowed destination host'
• CORS decides whether https://app.example.com is allowed to call the API from browser code

They answer different questions, so configuring one does not replace the other.

Middleware Order Matters for CORS

In ASP.NET Core 3.x, UseCors should typically run after UseRouting and before UseEndpoints. If you place it incorrectly, the policy may not apply to your controllers as expected.

The common pattern is:

1app.UseRouting();
2app.UseCors("Frontend");
3app.UseAuthentication();
4app.UseAuthorization();
5app.UseEndpoints(endpoints => endpoints.MapControllers());

AllowedHosts, by contrast, is driven by host filtering configuration and does not replace this middleware setup.

Common Pitfalls

• Using AllowedHosts to try to fix a browser CORS error. It does not control cross-origin browser access.
• Assuming CORS protects the API from all non-browser clients. Tools such as curl can still call the endpoint directly.
• Forgetting that AllowedHosts is about the request Host header, not the browser Origin header.
• Placing UseCors in the wrong position in the ASP.NET Core pipeline.
• Using overly broad CORS policies in development and forgetting to tighten them in production.

Summary

• 'AllowedHosts restricts accepted request host names at the server level.'
• 'UseCors controls which browser origins may access your API across origins.'
• 'AllowedHosts is about the Host header; CORS is about the Origin header and CORS response headers.'
• CORS is mainly a browser concern, while host filtering applies more broadly.
• In ASP.NET Core 3.x, configure UseCors in the middleware pipeline at the correct point or the policy may not take effect.