CORS preflight requests is not properly evaluated? + unclear CORS documentation

[tndata]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When I add CORS to my application and I specify a policy, for example:

options.AddDefaultPolicy(
builder =>
{
    builder.WithOrigins("http://localhost:5000", "https://localhost:5001")
        .AllowAnyHeader()
            .WithMethods("PUT", "DELETE");
});

Then my browser makes a preflight request to the API using:

OPTIONS http://myapi.local:7000/api/order/4 HTTP/1.1
Host: myapi.local:7000
Connection: keep-alive
Accept: */*
Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-my-custom-header
Origin: http://localhost:5000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Sec-Fetch-Mode: cors
Referer: http://localhost:5000/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,sv;q=0.8

Then the ASP.NET Core 6 (latest) returns

HTTP/1.1 204 No Content
Date: Wed, 09 Mar 2022 15:19:57 GMT
Server: Kestrel
Access-Control-Allow-Headers: x-my-custom-header
Access-Control-Allow-Methods: PUT,DELETE
Access-Control-Allow-Origin: http://localhost:5000
Vary: Origin

I am surprised that the server OK's this request where the allowed methods does not match.

the log from the CORS handlers says everything is fine:

info: TnData.CORS.CorsService[4]
      CORS policy execution successful.

Expected Behavior

So, I am a bit confused that the preflight request to the API with a non-allowed method (POST) is still allowed and the browser does not even seem to block it when I do a AJAX call using some simple test code like:

<script>
    // jQuery preflight request
    $.ajax({
        type: "POST",
        dataType: "json",
        headers: {"X-My-Custom-Header": "some value"},
        url: "http://identityService.local:7000/api/order/4",

        error: function(xhr, status, error){
                console.log("#########################");

                var errorMessage = xhr.status + ': ' + xhr.statusText;
                console.log(errorMessage);
                console.log("#########################");
                alert('Error - ' + errorMessage);
            },

        success: function(returnData){
            console.log("YYYYYYYYYYYEEEEEEEEEEEEESSSSSSSSSSSS");
            console.log(returnData);
            alert('DATA - ' + returnData);
            }
    });

</script>

Followup request after the preflight is still executed and so I am sooo confused when the allowed method missmatch stlil is allowed.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

6.0.201

Anything else?

So, I think also the documentation should be a bit more clear about the responsibilities of the CORS handler and what it actually enforces and when it blocks and not blocks. It seems that i checks if the origin matches, but it seem to when I look at the source code of the handler that the handler just "mirrors" the allowed-methods/headers.

Can I add custom code to actually enforce the preflight and block invalid methods or headers?

So, what does the handler actually block in the incoming preflight origin request?

[BrennanConroy]

A CORS-safelisted method is a method that is GET, HEAD, or POST.

The CORS spec specifies a few methods (the ones above) that are "safe" and browsers will basically ignore the Access-Control-Allow-Methods response header if any of those methods are used. As soon as you try something like "CUSTOM" you will see that it fails.

[ghost]

Hi @tndata. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.