在ASP.NET Core中启用CORS需先注册服务并定义策略，再将中间件添加到请求管道。1. 通过AddCors方法定义策略，指定允许的源、方法和头；2. 在UseRouting之后、UseAuthorization之前调用UseCors应用策略；3. 可使用[EnableCors]特性对控制器或方法进行细粒度控制。需避免AllowAnyOrigin与AllowCredentials共用，确保源完全匹配，并利用浏览器开发者工具排查预检请求问题。生产环境应明确指定可信源，结合配置文件实现多环境适配，确保安全与灵活性。
跨域请求（CORS，Cross-Origin Resource Sharing）是浏览器的一种安全机制，它允许运行在一个域下的Web应用程序访问另一个域下的资源。在ASP.NET Core中，CORS的启用和配置，本质上就是在服务器端明确告诉浏览器：“嘿，我允许来自这些特定源的请求访问我的资源。” 这样一来，当你的前端应用（比如运行在
http://localhost:3000
的React应用）尝试调用运行在
http://localhost:5000
的ASP.NET Core API时，浏览器就不会因为同源策略而拦截请求，而是会根据你服务器的CORS配置来决定是否放行。
解决方案
在ASP.NET Core中启用CORS，主要涉及两个步骤：注册CORS服务并定义策略，然后将CORS中间件添加到请求管道中。
在
Program.cs
中注册CORS服务并定义策略：
你需要通过
AddCors
方法将CORS服务添加到依赖注入容器中。在这里，你可以定义一个或多个CORS策略，指定哪些源（Origin）、哪些HTTP方法（Method）以及哪些HTTP头（Header）是被允许的。
// Program.csvar builder = WebApplication.CreateBuilder(args);// 添加CORS服务builder.Services.AddCors(options =>{ options.AddPolicy("MyAllowSpecificOrigins", // 策略名称，你可以随意命名 policy => { policy.WithOrigins("http://example.com", // 允许来自这些特定域名的请求 "http://localhost:3000") // 比如你的前端应用地址 .AllowAnyHeader() // 允许任何请求头 .AllowAnyMethod(); // 允许任何HTTP方法 (GET, POST, PUT, DELETE等) // .AllowCredentials(); // 如果需要支持凭据（如Cookie），请取消注释 }); // 也可以定义一个更宽松的策略，但通常不推荐在生产环境使用 options.AddPolicy("AllowAll", policy => { policy.AllowAnyOrigin() // 允许所有来源，生产环境慎用！ .AllowAnyHeader() .AllowAnyMethod(); });});// 其他服务注册...builder.Services.AddControllers();// ...var app = builder.Build();// 其他中间件配置...
在
Program.cs
中将CORS中间件添加到请求管道：
在定义了CORS策略之后，你需要通过
UseCors
方法将CORS中间件添加到ASP.NET Core的请求处理管道中。这一步告诉应用程序在处理请求时应用之前定义的CORS策略。
// Program.cs (接着上面的代码)app.UseRouting(); // CORS中间件通常应放在UseRouting()之后// 应用CORS策略。这里使用上面定义的特定策略。app.UseCors("MyAllowSpecificOrigins");// 如果你想在所有地方都应用宽松策略，可以这样：// app.UseCors("AllowAll");// 或者，如果你只定义了一个默认策略，可以直接使用：// app.UseCors();app.UseAuthorization(); // CORS中间件通常应放在UseAuthorization()之前app.MapControllers();app.Run();
可选：针对特定控制器或方法应用CORS策略
如果你只想对API中的特定控制器或Action方法应用CORS策略，可以使用
[EnableCors]
和
[DisableCors]
特性。
using Microsoft.AspNetCore.Cors;using Microsoft.AspNetCore.Mvc;[ApiController][Route("[controller]")]// [EnableCors("MyAllowSpecificOrigins")] // 应用到整个控制器public class MyDataController : ControllerBase{ [HttpGet] [EnableCors("MyAllowSpecificOrigins")] // 仅应用到此Action public IActionResult Get() { return Ok(new { Message = "Hello from API!" }); } [HttpPost] [DisableCors] // 禁用此Action的CORS，即使全局或控制器层面已启用 public IActionResult Post([FromBody] object data) { return Ok(); }}
为什么我们需要处理ASP.NET Core中的CORS问题？理解其背后的安全机制
说实话，刚接触CORS的时候，我感觉它简直就是个拦路虎，莫名其妙的“跨域错误”总能让人抓狂。但深入了解后，你会发现它其实是个尽职尽责的“门卫”，保护着我们的网络安全。CORS的出现，源于浏览器一个叫做“同源策略”（Same-Origin Policy, SOP）的核心安全机制。
简单来说，同源策略规定，一个网页的脚本只能访问与它同源的资源。这里的“同源”指的是协议（protocol）、域名（host）和端口（port）都相同。比如，
http://www.example.com:8080
只能访问
http://www.example.com:8080
下的资源，而不能直接访问
http://api.example.com:8080
或
https://www.example.com:8080
。这种限制是为了防止恶意网站通过JavaScript读取或修改用户在其他网站上的敏感数据，比如你登录银行网站后，另一个恶意网站就无法通过脚本偷偷读取你的账户信息。
然而，在现代Web开发中，前后端分离是主流。前端应用（比如运行在
app.mycompany.com
）经常需要调用后端API（可能运行在
api.mycompany.com
）。这时候，同源策略就成了障碍。CORS就是为了在遵守同源策略基本原则的前提下，提供一种受控的、安全的方式来“打破”这种限制。它允许服务器明确声明哪些外部源可以访问其资源。
当一个跨域请求发生时，浏览器会先发送一个“预检请求”（Preflight Request），这是一个
OPTIONS
类型的HTTP请求，它会询问服务器：“我来自
https://www.php.cn/link/ac82475ce1c53851409225be1c3ffa8e
，想用
POST
方法发送带有
Authorization
头的请求，你允许吗？”服务器收到这个请求后，会根据其CORS配置进行判断，然后返回一系列
Access-Control-Allow-*
的响应头。如果服务器允许，浏览器才会发送真正的跨域请求；否则，浏览器会直接拦截请求并抛出CORS错误。这个预检机制，就是CORS安全性的核心体现，它确保了在数据传输开始之前，双方就已经就跨域访问权限达成了共识。
所以，CORS并非添堵，它是一个必要的安全层，是我们构建安全、可信赖Web应用的关键一环。虽然配置起来偶尔会让人头疼，但它的存在确实为用户数据和系统安全提供了坚实的保障。
配置ASP.NET Core CORS策略时有哪些常见陷阱和最佳实践？
我在处理CORS问题上踩过的坑，简直可以写本书了。它不像其他配置，一个字母不对可能就整个服务挂掉，CORS更多的是那种“看起来没问题，但就是不工作”的隐形杀手。理解这些陷阱和最佳实践，能帮你省下大量抓耳挠腮的时间。
常见陷阱：
生产环境使用
AllowAnyOrigin()
： 这是最常见的，也是最危险的陷阱。开发时为了方便，我们可能直接
AllowAnyOrigin()
，但部署到生产环境后，这意味着任何网站都可以向你的API发起请求。虽然不一定能直接窃取数据（因为还有认证授权），但可能导致DDoS攻击、滥用你的API资源，甚至成为其他安全漏洞的跳板。务必在生产环境指定明确的源。
UseCors()
的放置位置错误：
UseCors()
中间件必须放在
UseRouting()
之后，
UseAuthorization()
之前。如果放在
UseRouting()
之前，CORS策略可能无法正确匹配路由；如果放在
UseAuthorization()
之后，一些需要授权的请求可能在CORS检查之前就被拦截，导致CORS错误信息不准确。遗漏
AllowCredentials()
： 如果你的前端应用需要发送凭据（如Cookie、HTTP认证头或客户端证书），并且后端API也需要处理这些凭据，那么你必须在CORS策略中明确调用
AllowCredentials()
。同时，
AllowCredentials()
不能与
AllowAnyOrigin()
一起使用，必须指定具体的源。这是因为
AllowAnyOrigin()
配合凭据会带来安全风险，浏览器会强制要求指定源。协议、域名或端口不匹配： 即使是
http://localhost:3000
和
http://localhost:3001
，对于CORS来说，它们也是不同的源。
http
和
https
更是天壤之别。一点点不匹配，都会导致CORS失败。我见过太多次，开发环境是
http
，生产环境是
https
，结果忘了更新CORS配置。预检请求（OPTIONS）未被正确处理： 有时候，
OPTIONS
请求本身就可能因为某些路由配置问题（比如你只允许
GET
请求，但没有明确允许
OPTIONS
）而失败，导致后续的实际请求根本不会发出。CORS策略通常会自动处理
OPTIONS
请求，但如果你的自定义路由或中间件过于激进，可能会干扰它。
最佳实践：
明确指定允许的源： 永远在生产环境中使用
WithOrigins()
，列出所有合法的、需要访问你API的前端域名。这就像给你的API设了一张白名单。
使用命名策略： 通过
AddPolicy("PolicyName", ...)
定义多个命名策略，可以让你在不同场景下（例如，一个策略用于公共API，另一个用于内部管理后台）应用不同的CORS规则，代码也更清晰易读。
理解
AllowCredentials()
的含义： 只有当你的API需要处理前端发送的Cookie、HTTP认证或客户端证书时才使用
AllowCredentials()
。如果不需要，就不要加，减少不必要的复杂性。
环境特定配置： 利用ASP.NET Core的环境配置能力，为开发、测试和生产环境配置不同的CORS策略。例如，开发环境可以允许
localhost
，而生产环境则只允许你的正式域名。
// appsettings.Development.json"CorsOrigins": "http://localhost:3000,http://localhost:4200"// appsettings.Production.json"CorsOrigins": "https://yourfrontend.com"
然后在
Program.cs
中读取配置：
var allowedOrigins = builder.Configuration.GetValue("CorsOrigins")?.Split(',') ?? new string[0];options.AddPolicy("MyAllowSpecificOrigins", policy => policy.WithOrigins(allowedOrigins).AllowAnyHeader().AllowAnyMethod());
细粒度控制： 如果你的API有公共接口和私有接口，可以考虑在全局配置一个默认的、相对宽松的CORS策略，然后使用
[EnableCors]
和
[DisableCors]
特性在控制器或Action级别进行更精细的覆盖和调整。
优先考虑安全性： 始终以最严格的CORS策略开始，然后根据实际需求逐步放宽。不要为了图省事一开始就
AllowAnyOrigin()
。
这些经验教训，都是在无数次“为什么我的API不工作”的疑问中总结出来的。CORS配置虽然看似简单，但其背后的安全考量和细节处理，往往决定了你的应用能否稳定、安全地运行。
如何在ASP.NET Core中调试和解决CORS相关问题？
调试CORS问题，有时感觉就像在黑暗中摸索，因为错误信息往往是浏览器给出的，而服务器端可能什么异常都没抛。但只要掌握一些方法和工具，就能让这个过程变得清晰起来。
从浏览器开发者工具入手：
控制台（Console）: 这是你首先要看的地方。浏览器会在这里打印出详细的CORS错误信息，比如“No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”（缺少CORS头）、“Origin ‘https://www.php.cn/link/ac82475ce1c53851409225be1c3ffa8e’ is therefore not allowed access.”（来源不被允许）等。这些信息直接指出了问题所在。网络（Network）选项卡：查看预检请求（OPTIONS）： 找到你的API请求，如果它是跨域的，通常会有一个
OPTIONS
类型的预检请求。检查这个请求的响应头。关键响应头： 寻找
Access-Control-Allow-Origin
、
Access-Control-Allow-Methods
、
Access-Control-Allow-Headers
等。确保
Access-Control-Allow-Origin
的值与你的前端应用的源完全匹配（包括协议、域名和端口）。如果你的前端发送了自定义头或使用了非简单HTTP方法（如
PUT
、
DELETE
），确保
Access-Control-Allow-Headers
和
Access-Control-Allow-Methods
包含了它们。HTTP状态码： 预检请求的成功状态码通常是200 OK或204 No Content。如果返回其他错误码（如404、500），那说明预检请求本身就没被服务器正确处理，问题可能出在路由或服务器端异常。
检查ASP.NET Core服务器端日志：
虽然ASP.NET Core的CORS中间件本身不会打印特别详细的失败日志，但如果你的CORS配置导致了服务器端异常（比如在
UseCors
之前发生了其他中间件错误），这些信息会在服务器日志中体现。考虑添加自定义日志：你可以在CORS中间件前后添加自定义日志，或者在CORS策略的构建器中尝试捕获一些信息，来了解策略是否被正确应用。确保你的
Program.cs
中
UseCors()
的位置正确。
使用Postman或Insomnia等API工具：
这些工具不会像浏览器那样强制执行同源策略。这意味着你可以用它们来直接测试你的API，看它是否能正常响应，以及是否返回了正确的CORS响应头。如果Postman能成功访问API，但浏览器不行，那么问题几乎肯定出在CORS配置上。如果Postman也失败，那可能是API本身的问题（如认证、授权、路由错误等）。
逐步简化配置：
如果问题难以定位，尝试将CORS配置简化到最宽松的程度（例如，暂时使用
AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod()
），然后逐步收紧。如果宽松配置下工作正常，说明问题出在你收紧策略的某个环节。检查所有相关的CORS策略：确保你期望应用的策略名称与
UseCors()
或
[EnableCors]
中使用的名称一致。
常见错误场景及排查：
“No ‘Access-Control-Allow-Origin’ header…”： 最常见，意味着服务器根本没有发送CORS头，或者发送的头不匹配。检查
WithOrigins()
是否包含前端源，
UseCors()
是否被调用。“The ‘Access-Control-Allow-Credentials’ header cannot be used…”： 提示你同时使用了
AllowAnyOrigin()
和
AllowCredentials()
。你需要将
AllowAnyOrigin()
替换为具体的
WithOrigins()
。“Method not allowed”： 检查
AllowAnyMethod()
是否被调用，或者
WithMethods()
是否包含了你请求的HTTP方法。“Header not allowed”： 检查
AllowAnyHeader()
是否被调用，或者
WithHeaders()
是否包含了你请求中使用的自定义头。
CORS调试确实考验耐心，因为它需要你同时关注前端和后端，理解HTTP请求的生命周期。但一旦你掌握了这些工具和方法，它就从一个“玄学”问题变成了可以按部就班解决的技术问题。很多时候，就是某个源的协议、域名或端口没对上，或者
AllowCredentials()
的限制没注意到，这些小细节往往是问题的症结。
以上就是ASP.NET Core中的跨域请求（CORS）是什么？如何启用？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439215.html
微信扫一扫 
支付宝扫一扫 
