ASP.NET Core API搭配Swagger，是否真的需要配置CORS？

我开发了一个提供公开公司数据的API，这些数据对黑客没有价值，也能从其他网站获取。项目是用Visual Studio默认的ASP.NET Core API模板创建的，发现里面自带了CORS配置，不清楚它的来源。当前默认策略设置为允许任何域、任何方法以及任何请求头：

builder.Services.AddCors(p =>
    p.AddPolicy("corsapp", builder =>
        {
            builder.WithOrigins("*").AllowAnyMethod().AllowAnyHeader();
        }));

我有几个疑问：

• 如果只允许单个启用HTTPS的源访问这个API，我还需要配置CORS吗？
• 当前API运行正常，配置CORS能带来什么益处？

附上我的Program.cs代码：

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

//do I really need this!?!
builder.Services.AddCors(p => p.AddPolicy("corsapp", builder =>
{
    builder.WithOrigins("*").AllowAnyMethod().AllowAnyHeader();
}));

var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

startup.Configure(app);

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

//why!?!
app.UseCors("corsapp");

app.UseAuthorization();

app.MapControllers();

app.Run();

更新
我看完相关的CORS讲解后重新梳理了问题，但还是纠结要不要把CORS配置成仅允许单一源访问，担心后续维护者在需要多源访问API时会配置出错。

1. 仅允许单个HTTPS源访问时，是否需要CORS？ #

需要。CORS是浏览器层面的安全机制，只要你的API是被浏览器端的前端页面（比如React、Vue项目）跨域调用，就必须配置CORS——哪怕只有一个源。如果没有正确配置，浏览器会直接拦截前端发起的跨域请求，返回错误，哪怕API本身运行正常。

如果你的API仅被后端服务调用（比如其他.NET程序、Python脚本），浏览器的CORS机制不会生效，这时候可以不用配置。但如果是给前端页面提供服务，无论源的数量多少，都得配置。

2. 配置CORS的益处 #

• 浏览器层面的访问控制：哪怕数据是公开的，也能限制只有指定的前端域名能调用你的API，避免被恶意网站嵌入调用（比如垃圾网站爬取你的API数据填充自身页面）。
• 符合浏览器安全规范：现代浏览器强制遵循同源策略，没有正确的CORS配置，前端跨域请求必然失败，直接导致API无法被前端正常使用。
• 明确访问规则：配置CORS相当于给API设定了清晰的访问权限，后续维护者能一眼看出哪些源可以访问API，减少误操作概率。

3. 关于单一源配置的纠结 #

建议你现在就配置成仅允许当前需要的单一HTTPS源，理由如下：

• 最小权限原则：安全配置的核心是只开放必要权限，避免过度开放带来的潜在风险——哪怕现在数据是公开的，未来万一API新增敏感接口，过度开放的CORS会留下隐患。
• 便于后续修改：如果以后需要添加多源访问，修改配置很简单，只需在WithOrigins里添加新域名即可，比如：

  builder.WithOrigins("https://your-first-domain.com", "https://your-second-domain.com")
         .AllowAnyMethod()
         .AllowAnyHeader();
  

  只要在注释里明确说明配置规则（比如“新增允许访问的源时，直接在WithOrigins列表中添加HTTPS域名”），后续维护者很难配置出错。
• 避免当前的过度开放风险：你现在的配置是允许任何源访问，相当于完全关闭了CORS的访问控制，任何网站都能调用你的API，可能导致API请求量激增，影响服务稳定性。

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