CORS (Cross-Origin Resource Sharing)

builder.Services.AddCors(options => {
    options.AddPolicy("AllowFrontend", policy => {
        policy.WithOrigins("https://app.mycompany.com").AllowAnyMethod().AllowAnyHeader();
    });
});

app.UseCors("AllowFrontend");

Common follow-ups: What exactly counts as a different 'origin' (scheme, host, port)?;Why is CORS enforced by the browser rather than being a server-side security boundary?

app.UseRouting();
app.UseCors("MyPolicy");   // after routing, before authorization
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

Common follow-ups: What HTTP status does a rejected preflight request typically show in browser dev tools?;How does this ordering interact with endpoint-specific [EnableCors] attributes?

// Browser automatically sends BEFORE a PUT request with a custom header:
// OPTIONS /api/products/5
// Access-Control-Request-Method: PUT
// Access-Control-Request-Headers: X-Custom-Header

// Server must respond with matching Access-Control-Allow-Methods/Headers

Common follow-ups: What HTTP methods/headers count as 'simple' and avoid triggering a preflight?;How can preflight results be cached client-side to avoid repeating them on every request?

// INVALID combination -- throws at runtime
// policy.AllowAnyOrigin().AllowCredentials();

// Correct: specific origins required with credentials
policy.WithOrigins("https://app.mycompany.com")
      .AllowCredentials()
      .AllowAnyHeader().AllowAnyMethod();

Common follow-ups: Why is combining wildcard origins with credentials considered a security risk?;How do JWT bearer tokens sidestep this particular constraint compared to cookies?

builder.Services.AddCors(options => {
    options.AddPolicy("PublicApi", p => p.AllowAnyOrigin().WithMethods("GET"));
    options.AddPolicy("AdminApi", p => p.WithOrigins("https://admin.mycompany.com").AllowCredentials());
});

[EnableCors("PublicApi")]
public class ProductsController : ControllerBase { }

app.MapGroup("/admin").RequireCors("AdminApi");

Common follow-ups: What happens if both a global UseCors default policy and a per-endpoint policy are present?;How does [DisableCors] interact with a permissive global default?

// DANGEROUS anti-pattern: reflecting any origin defeats CORS's entire purpose
policy.SetIsOriginAllowed(origin => true).AllowCredentials();

// SAFE: explicit allowlist of known, trusted origins only
policy.WithOrigins("https://app.mycompany.com", "https://admin.mycompany.com").AllowCredentials();

Common follow-ups: How would an attacker actually exploit an overly permissive CORS + credentials configuration?;What's the safe way to support multiple known frontend origins instead?

policy.SetIsOriginAllowed(origin => {
    var uri = new Uri(origin);
    return uri.Host.Equals("mycompany.com", StringComparison.OrdinalIgnoreCase) ||
           uri.Host.EndsWith(".mycompany.com", StringComparison.OrdinalIgnoreCase);
}).AllowCredentials();

Common follow-ups: What's the risk of a naive string.Contains() check instead of proper suffix matching here?;How would you unit test this custom origin-matching logic thoroughly?

builder.Services.AddCors(options => {
    options.AddPolicy("MyPolicy", policy => {
        policy.WithOrigins("https://app.mycompany.com")
              .WithExposedHeaders("X-Total-Count", "X-Page-Number");
    });
});

// Now client JS can read: response.headers.get('X-Total-Count')

Common follow-ups: Why are only a small set of headers readable by default without this configuration?;How does this differ for same-origin requests, which have no such restriction?

// Browser only ever talks to the gateway origin:
// fetch('https://api.mycompany.com/orders')  -- gateway handles CORS
// Gateway internally routes to http://orders-service:8080 (no CORS needed here,
// since this is server-to-server, not browser-to-server)

Common follow-ups: What CORS considerations remain if a gateway does server-side aggregation calling multiple backends?;How does this simplification break down if some services are exposed directly, bypassing the gateway?

<!-- A malicious site can still trigger this request (CSRF), even with strict CORS,
     because a simple form POST doesn't require reading the response -->
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="10000">
</form>
<!-- CORS prevents the attacker's JS from READING the response, but the transfer may still happen -->

Common follow-ups: How do anti-forgery tokens provide CSRF protection that CORS can't?;Why is SameSite cookie configuration also relevant here?