Client-server architecture separates the user interface from data storage and application concerns. A browser or other client sends requests; the web API responds without needing to know how that client was built. This separation lets each side change independently and helps keep the system simpler to maintain. section 1.1.4 section 3.1.1
For a web API, the boundary is practical: controllers and Minimal APIs return standard HTTP responses rather than client-specific output. The API responds to client-initiated requests; it does not initiate requests to clients. section 3.1.1
A separate client still needs permission to call the API from a browser. The same-origin policy restricts scripts from requesting a different protocol, host, or port. Cross-Origin Resource Sharing (CORS) uses HTTP headers to permit selected cross-origin requests. It controls browser access; it does not change the separation between client and server. section 3.1.1
builder.Services.AddCors(options => {
options.AddDefaultPolicy(cfg => {
cfg.WithOrigins(builder.Configuration["AllowedOrigins"]);
cfg.AllowAnyHeader();
cfg.AllowAnyMethod();
});
options.AddPolicy(name: "AnyOrigin",
cfg => {
cfg.AllowAnyOrigin();
cfg.AllowAnyHeader();
cfg.AllowAnyMethod();
});
});
This ASP.NET Core configuration registers a default CORS policy using AllowedOrigins and a named AnyOrigin policy. Both permit any header and method, but the named policy permits any origin; choose the policy appropriate to the clients that need access. section 3.1.1
After registering a policy, add CORS middleware with app.UseCors() or apply a named policy to selected endpoints with RequireCors("AnyOrigin"). This makes cross-origin access an explicit API configuration decision. section 3.1.1
