如何配置IIS托管的ASP.NET Core应用允许任意跨域请求？

核心原则 #

不要同时在IIS和ASP.NET Core应用层重复配置CORS，二者任选其一，推荐统一在应用内处理——IIS的CORS配置容易和ASP.NET Core的管道逻辑冲突，导致各种预检失败、头重复的问题。

步骤1：清理IIS的CORS相关干扰配置 #

1. 移除IIS手动添加的CORS响应头：打开IIS管理器，找到目标站点/应用，进入「HTTP响应头」，删除所有Access-Control-*开头的自定义头。
2. 禁用/卸载IIS CORS模块：如果之前安装了IIS官方的CORS模块，要么直接卸载，要么在应用的web.config里添加<cors enabled="false" />禁用它对当前应用的作用。
3. 让OPTIONS请求传递到ASP.NET Core管道：IIS默认的OPTIONSVerbHandler会拦截预检用的OPTIONS请求，导致应用的CORS中间件无法处理。修改web.config的handlers节点：

<configuration>
  <system.webServer>
    <handlers>
      <!-- 移除默认的OPTIONS请求处理器 -->
      <remove name="OPTIONSVerbHandler" />
      <!-- 确保ASP.NET Core模块处理所有请求（包括OPTIONS） -->
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\YourApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
    <!-- 禁用IIS CORS模块（如果已安装） -->
    <cors enabled="false" />
  </system.webServer>
</configuration>

步骤2：在ASP.NET Core应用内正确配置CORS #

推荐使用官方提供的AddCors扩展方法（比自定义中间件更规范，能处理所有CORS细节）：

var builder = WebApplication.CreateBuilder(args);

// 配置CORS服务，设置允许任意跨域的默认策略
builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.AllowAnyOrigin()
              .AllowAnyMethod()
              .AllowAnyHeader();
        
        // 如果需要支持带凭证（Cookie/Token）的跨域请求，替换上面的AllowAnyOrigin为以下配置：
        // policy.SetIsOriginAllowed(_ => true)
        //       .AllowAnyMethod()
        //       .AllowAnyHeader()
        //       .AllowCredentials();
    });
});

// 添加控制器服务（根据你的应用类型调整，比如AddControllersWithViews等）
builder.Services.AddControllers();

var app = builder.Build();

// 注意中间件顺序：UseCors必须放在UseRouting之后，UseAuthorization之前
app.UseRouting();
app.UseCors(); // 启用CORS中间件
app.UseAuthorization();

app.MapControllers();

app.Run();

为什么之前会出现各种错误？ #

1. IIS未配置头但应用配置了却提示缺少头：IIS的OPTIONSVerbHandler拦截了预检OPTIONS请求，ASP.NET Core的CORS中间件根本没机会处理请求，自然不会返回CORS头。
2. IIS和应用同时加头导致重复：浏览器要求Access-Control-Allow-Origin只能有一个值，重复配置会直接触发报错。
3. 仅IIS加头导致预检失败：IIS只能添加静态响应头，无法正确处理OPTIONS预检请求的逻辑（比如返回200状态、匹配请求方法/头的校验），导致浏览器判定预检不通过。

内容的提问来源于stack exchange，提问作者ILIA BROUDNO