4

At step 3 in the W3C Cross Origin Resource Sharing recommendations (http://www.w3.org/TR/cors/#resource-requests) it states:

If the resource supports credentials add a single Access-Control-Allow-Origin header, with the value of the Origin header as value, and add a single Access-Control-Allow-Credentials header with the case-sensitive string "true" as value.

Otherwise, add a single Access-Control-Allow-Origin header, with either the value of the Origin header or the string "*" as value.

The string "*" cannot be used for a resource that supports credentials.

This is then reflected in code like this:

if (policy.AllowAnyOrigin)
{
    if (policy.SupportsCredentials)
    {
        result.AllowedOrigin = origin;
        result.VaryByOrigin = true;
    }
    else
    {
        result.AllowedOrigin = CorsConstants.AnyOrigin;
    }
}
else if (policy.Origins.Contains(origin))
{
    result.AllowedOrigin = origin;
}

https://github.com/aspnet/CORS/blob/release/src/Microsoft.AspNet.Cors/CorsService.cs#L219

My question is how is this at all secure? What is the point of a browser refusing * in the allowed origins when credentials are allowed if the server is instructed just to work around the restriction anyway?

ABJones
  • 41
  • 2
  • 1
    This is *not* secure! -- it's essentially doing the C# version of the "workaround" posted here: http://stackoverflow.com/a/25623518/398630 -- This code defeats the purpose of the CORS restriction. – BrainSlugs83 Jan 15 '16 at 07:04

1 Answers1

0

The comment by @BrainSlugs83 appears to answer the question, so I'm copying it here:

This is not secure! -- it's essentially doing the C# version of the "workaround" posted here: https://stackoverflow.com/a/25623518/398630

This code defeats the purpose of the CORS restriction.

Community
  • 1
  • 1
Nickolay
  • 31,095
  • 13
  • 107
  • 185