Recommended Free Tools
CORS in .NET Core lets you specify which browser-based applications may read responses from your API. Configure it with explicit trusted origins and only the methods and headers your client needs. It is not authentication, authorization, or a general security boundary: CORS does not stop other clients from sending requests, and it does not replace protection against cross-site request forgery (CSRF).
This guide follows Microsoft’s ASP.NET Core 10.0 guidance, whose CORS page was last updated May 12, 2026. Microsoft Learn: Enable Cross-Origin Requests (CORS) in ASP.NET Core
What CORS does—and what it does not do
Browsers enforce the same-origin policy, which restricts client-side code from reading responses from a different origin. An origin is defined by its scheme, host, and port. For example, https://app.example.com and https://api.example.com are different origins. CORS (Cross-Origin Resource Sharing) is a browser mechanism that lets a server relax that restriction for origins it chooses.
The browser checks the API’s CORS response headers to decide whether JavaScript running on another origin can access the response. CORS does not stop a request from reaching the server, and it does not stop non-browser clients from reading a response. Microsoft’s documentation puts it plainly: “CORS is not a security feature.” Microsoft Learn, ASP.NET Core 10.0 CORS guidance
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
- CORS controls: whether a browser permits client-side code on another origin to access a response.
- Authentication controls: who the caller is.
- Authorization controls: what an authenticated caller may do.
- CSRF protections control: whether a browser can be induced to submit an unwanted request using a user’s existing credentials.
Use CORS to scope browser access, not as a substitute for API authentication, authorization, or antiforgery protections.
Configure a least-privilege CORS policy
For a browser client hosted at https://app.example.com, allow that exact origin and only the API methods and request headers the application needs. The following named policy is an example; replace the methods and headers with those your client actually uses.
builder.Services.AddCors(options =>
{
options.AddPolicy("BrowserClient", policy =>
{
policy.WithOrigins("https://app.example.com")
.WithMethods("GET", "POST")
.WithHeaders("Content-Type", "Authorization");
});
});Apply the named policy in the middleware pipeline:
app.UseRouting();
app.UseCors("BrowserClient");
app.UseAuthentication();
app.UseAuthorization();The origin must match the browser’s Origin value, including scheme, host, and any non-default port. Do not add a trailing slash to a value passed to WithOrigins. Microsoft documents separate controls for origins, methods, request headers, and exposed response headers in its ASP.NET Core CORS configuration guidance.
Allow only required origins, methods, and headers
WithOrigins(...)specifies which origins may access responses through a browser.WithMethods(...)limits the HTTP methods allowed by the policy.WithHeaders(...)limits the request headers clients may send under the policy. Header matching is exact: if the browser’s preflight requests a header that the policy omits, the policy may not return CORS headers.
A method or header not included in the policy is not automatically allowed simply because the origin is trusted. Check the actual browser requests before adding permissions.
Rank #2
Expose response headers only when needed
JavaScript cannot read every response header by default. If browser code needs a particular response header, expose it explicitly:
policy.WithExposedHeaders("X-Request-Id");Use the response header your API actually returns; exposing a header does not add it to the response.
Use wildcard subdomains cautiously
If several subdomains genuinely need access, Microsoft provides SetIsOriginAllowedToAllowWildcardSubdomains for a wildcard origin pattern. For example:
policy.WithOrigins("https://*.example.com")
.SetIsOriginAllowedToAllowWildcardSubdomains();This broadens trust to matching subdomains. Use it only when every eligible subdomain is under your control and has an appropriate security posture; a specific origin is safer when it meets the requirement.
Free tools Windows power users keep installed
One-click scans. No signup required.
Understand preflight requests
For some cross-origin requests, the browser first sends an OPTIONS preflight request to ask whether the actual request is permitted. The preflight includes the origin and may include the intended method and request headers. The server’s CORS policy must allow them before the browser proceeds with the actual operation.
A preflight can fail even if the server returns a successful HTTP status. If the response lacks the CORS headers the browser expects, the browser blocks the cross-origin operation. A policy mismatch can also result in no CORS headers at all. Microsoft documents preflight behavior and CORS troubleshooting.
Diagnose a preflight failure
- Open the browser’s developer tools and select the Network panel.
- Find the failing
OPTIONSrequest. Inspect itsOrigin,Access-Control-Request-Method, andAccess-Control-Request-Headersvalues. - Compare the origin and requested method with the policy’s
WithOriginsandWithMethodsentries. - Compare every requested header with
WithHeaders. Microsoft notes that specified header values must match the requested headers exactly. - Inspect the response for the expected
Access-Control-Allow-Origin,Access-Control-Allow-Methods, andAccess-Control-Allow-Headersvalues. If they are absent or do not match, correct the policy or the request, rather than treating a successful status code as proof that CORS passed.
Messages such as “No ‘Access-Control-Allow-Origin’ header is present” or “Response to preflight request doesn’t pass access control check” point to the browser’s CORS check. They do not, by themselves, identify whether the cause is an origin mismatch, an unapproved method or header, middleware placement, or another server-side response problem.
Allow credentials only for a specific trusted origin
Cross-origin browser requests that include cookies or other browser-managed credentials require participation by both client and server. On the server, allow a specific origin and opt in to credentials:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRank #4
builder.Services.AddCors(options =>
{
options.AddPolicy("BrowserClientWithCookies", policy =>
{
policy.WithOrigins("https://app.example.com")
.WithMethods("GET", "POST")
.WithHeaders("Content-Type")
.AllowCredentials();
});
});For a Fetch request, the client must also opt in:
fetch("https://api.example.com/data", {
credentials: "include"
});Microsoft warns that “Allowing cross-origin credentials is a security risk.” A permitted origin may make requests that carry a signed-in user’s credentials, so enable this only for origins you trust. Credentialed CORS cannot be combined with an unrestricted * origin; specify the allowed origin explicitly. Microsoft Learn, ASP.NET Core 10.0 CORS guidance
CORS is separate from CSRF protection
A CORS policy determines whether browser code from an origin may read a response; it is not proof that an incoming request is legitimate and does not, by itself, prevent a cross-site request from being sent. Applications that use cookies or other automatically attached credentials still need to evaluate and implement appropriate CSRF defenses.
ASP.NET Core’s antiforgery guidance discusses CORS together with trust decisions for certain cross-origin form scenarios. In that context, an origin-specific policy with AllowCredentials is a trust signal; AllowAnyOrigin is not trusted for writes. That guidance does not make CORS a replacement for antiforgery validation. Microsoft Learn: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core
Place CORS correctly in the middleware pipeline
Middleware order affects whether the CORS policy can handle a request and whether the response has the expected headers. Microsoft’s middleware guidance shows CORS before authentication and authorization, and specifies that CORS must run before response caching so CORS headers are added to cached responses. Microsoft Learn: ASP.NET Core middleware
app.UseRouting();
app.UseCors("BrowserClient");
app.UseAuthentication();
app.UseAuthorization();
app.UseResponseCaching();If static-file responses need CORS headers, placement depends on which responses require CORS. Consult Microsoft’s CORS documentation on ordering UseCors and UseStaticFiles and place the middleware accordingly.
Choose the policy scope that fits the API
ASP.NET Core supports policies applied at different scopes. Choose the narrowest scope that fits how your endpoints are organized.
| Policy approach | Where it applies | Useful when |
|---|---|---|
| Default policy | Applied globally when CORS is enabled without naming a policy. | The same CORS rules are appropriate for the entire application. |
| Named policy | Selected by its name in middleware or endpoint configuration. | One policy should be reusable across a set of endpoints. |
| Endpoint-specific policy | Applied to individual endpoints or controllers. | Different API areas require distinct browser-access rules. |
Policy scope does not change what CORS means: each policy still needs deliberate decisions about origins, methods, headers, credentials, and any response headers the browser must read. For the available ASP.NET Core 10.0 configuration patterns, see Microsoft’s CORS documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
