CORS & Cross-Origin Resource Sharing

// Page served from https://myapp.com trying to call https://api.otherapp.com
fetch('https://api.otherapp.com/data')
  .then(r => r.json());
// Blocked by the browser unless api.otherapp.com's response includes
// Access-Control-Allow-Origin: https://myapp.com (or *)

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

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

app.UseCors("AllowFrontend");  // after UseRouting, before UseAuthorization

Common follow-ups: Why must UseCors be positioned specifically between UseRouting and UseAuthorization?;How do you apply different CORS policies to different controllers?

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

// Server must respond with:
// Access-Control-Allow-Methods: PUT
// Access-Control-Allow-Headers: X-Custom-Header

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

// This configuration throws an exception at runtime:
// policy.AllowAnyOrigin().AllowCredentials();  // INVALID combination

// 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 CORS/credentials constraint?

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 { }

[EnableCors("AdminApi")]
public class AdminController : ControllerBase { }

Common follow-ups: What happens if both a global UseCors policy and an [EnableCors] attribute are present?;How would [DisableCors] interact with a permissive global default policy?

app.UseRouting();        // must be first: matches endpoint metadata
app.UseCors("MyPolicy");  // must be here: needs endpoint match, but before auth
app.UseAuthentication();
app.UseAuthorization();   // preflight OPTIONS requests never reach this far incorrectly

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?

// DANGEROUS anti-pattern: reflecting any origin defeats CORS's purpose
policy.SetIsOriginAllowed(origin => true)  // allows literally ANY origin
      .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?

builder.Services.AddCors(options => {
    options.AddPolicy("KnownFrontends", policy => {
        policy.WithOrigins(
            "https://app.mycompany.com",
            "https://staging.mycompany.com",
            "http://localhost:3000"  // local dev
        ).AllowAnyMethod().AllowAnyHeader();
    });
});

Common follow-ups: Should localhost origins ever be included in a production CORS policy?;How do you manage this origin list across different deployment environments?

// 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 (like ASP.NET Core's built-in ones) provide CSRF protection CORS can't?;Why is SameSite=Strict/Lax cookie configuration also relevant here?