Cors Wildcard in Aspnet (Csharp)

In AspNet applications written in C#, a CORS wildcard configuration allows requests from any origin. When combined with credentials or overly permissive headers, this introduces a cross-origin risk where unauthorized sites can leverage the browser to make authenticated requests on behalf of users. The C# implementation typically resides in Startup.cs or Program.cs using app.UseCors and services.AddCors. A common insecure pattern is:

services.AddCors(options =>
{
    options.AddPolicy("AllowAll", builder =>
    {
        builder.AllowAnyOrigin()
               .AllowAnyMethod()
               .AllowAnyHeader()
               .AllowCredentials();
    });
});

The combination of AllowAnyOrigin() with AllowCredentials() is disallowed by most browsers and violates the CORS specification because a wildcard origin cannot be used when credentials are exposed. This misconfiguration can lead to credential leakage where a malicious site triggers cross-origin requests that include cookies or authentication headers, effectively bypassing same-origin policy protections. The risk is especially pronounced if the application also exposes non-simple requests or custom headers that are not adequately validated.

In the context of an unauthenticated scan, middleBrick tests whether the CORS policy reflects sensitive endpoints and whether wildcard origins expose authentication or sensitive headers. Findings may map to the Authentication and BOLA/IDOR checks, highlighting that permissive CORS rules can weaken access control boundaries. When scanning an AspNet API implemented in C#, middleBrick inspects the runtime behavior of CORS headers and flags configurations where Access-Control-Allow-Origin is set to * while credentials are permitted. Remediation guidance emphasizes replacing the wildcard with specific origins and tightening header and method allowances to align with the principle of least privilege.

Additionally, if the C# application serves both API and UI origins, failing to separate or explicitly list origins can lead to privilege escalation where an untrusted origin inherits elevated permissions. The scan also evaluates whether preflight responses are overly permissive and whether exposed headers inadvertently disclose sensitive information, tying into Data Exposure and Property Authorization checks. Developers should ensure that CORS policies are defined with explicit origins, constrained methods, and validated headers, avoiding the use of wildcards in production environments that handle authenticated traffic.

To remediate CORS wildcard issues in AspNet with C#, replace the permissive policy with an explicit origin list and remove credentials from wildcard rules. Below is a secure C# example using the minimal API model in .NET 6+:

var builder = WebApplication.CreateBuilder(args);

// Define a specific origin or read from configuration
var allowedOrigin = builder.Configuration["Cors:AllowedOrigin"] ?? "https://app.example.com";

builder.Services.AddCors(options =>
{
    options.AddPolicy("SecureCorsPolicy", builder =>
    {
        builder.WithOrigins(allowedOrigin)
               .WithMethods("GET", "POST", "PUT", "DELETE")
               .WithHeaders("Content-Type", "Authorization", "X-Requested-With")
               .AllowCredentials();
    });
});

var app = builder.Build();
app.UseCors("SecureCorsPolicy");
app.MapGet("/values", () => "Secure");
app.Run();

For projects using the traditional Startup pattern, the equivalent C# configuration in ConfigureServices and Configure is:

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("SecureCorsPolicy", builder =>
        {
            builder.WithOrigins("https://trusted.example.com", "https://app.example.com")
                   .AllowAnyHeader()
                   .WithMethods("GET", "POST")
                   .AllowCredentials();
        });
    });
    services.AddControllers();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseRouting();
    app.UseCors("SecureCorsPolicy");
    app.UseAuthorization();
    app.UseEndpoints(endpoints => endpoints.MapControllers());
}

In both examples, credentials are retained but the origin is explicitly restricted, which satisfies browser security requirements and reduces the attack surface. You can further tighten the policy by avoiding AllowAnyHeader and instead specifying only required headers, and by limiting HTTP methods to those strictly necessary. middleBrick’s Pro plan supports continuous monitoring of such configurations, alerting you if a wildcard origin reappears after deployment. The GitHub Action can enforce a threshold by failing builds when insecure CORS rules are detected in the runtime or spec analysis.

Additional best practices include using environment-specific configuration to ensure development wildcards are not promoted to production, validating origins against a denylist of known malicious domains, and ensuring that CORS does not replace proper authentication and authorization checks. The MCP Server allows you to scan APIs directly from your AI coding assistant, surfacing CORS issues inline as you write C# code, which complements the dashboard and CLI workflows offered by middleBrick.