CORS Preflight requests

[hamburml]

Hello there!

I have a question about CORS with preflight/options request. Here is a short example: https://github.com/hamburml/quarkus-cors-example.

An app on localhost:3001 makes a POST request with custom header to another app developer with quarkus on localhost:8080. The custom header forces a preflight request (HTTP Header OPTIONS) which asks the localhost:8080 app if it is allowed to send a request with the custom header for example. Inside the quarkus app I set quarkus.http.cors.methods=GET,DELETE so requests with Methods POST should be disallowed.

But that is not the case. Here is the screenshot of developer tools.

Access-control-request-method is set to POST but the status code is 200.

Quarkus config is here: https://github.com/hamburml/quarkus-cors-example/blob/main/quarkus_8080/src/main/resources/application.properties

Thanks!

[hamburml]

I think https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/cors/CORSFilter.java#L219 here needs to be another check if not only the origin is not allowed but also the method.

[sberyozkin]

Hi @hamburml

Access-Control-Allow-Methods has not been returned in this case.

Note for Origin, when there was a mismatch, we used to return 200 without Access-Cotrol-Allowed-Origins which was enough to block the request - though recently we switched to also returning 403 instead of 200.
Has the actual POST method gone ahead, despite the preflight HTTP status code being 200 ? We can fix it to return 403 in case of the mismatched methods as well.

[hamburml]

Hi @sberyozkin,

Access-Control-Allow-Methods has not been returned in this case.

true, i only checked the status code (I assumed 200 tells the browser that the cors preflight is valid and the actual request can be made).

Has the actual POST method gone ahead, despite the preflight HTTP status code being 200

yeah, the post request was send from Chrome after the preflight HTTP was 200. In the screenshot it is the second "hello" request (but it is above the preflight, sorting is kinda off in the screenshot).

Shouldn't Access-Control-Allow-Methods be returned with the allowed http methods? https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests specific: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#access-control-allow-methods

[hamburml]

Interesting. It looks like cors preflight response should always be 200 or 204 but the cors headers must be set. I just read https://fetch.spec.whatwg.org/#http-requests.

A successful HTTP response, i.e., one where the server developer intends to share it, to a CORS request can use any status, as long as it includes the headers stated above with values matching up with the request. A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204.

Maybe 403 can be used for compatibility reason.

To make it short: I think the allow-methods header should be set. I am not well-versed enough to decide if it should be 200, 204 or 403 but I think 403 is the most compatible (and only set status code 200 if the cors preflight request is valid and the actual request can be made).

[sberyozkin]

@hamburml oh yes, you need to configure the filter with the list of allowed methods if you'd like to restrict

[sberyozkin]

It can't just echo the incoming header value back

[hamburml]

I could try a PullRequest :) Maybe I will find some free time tomorrow. I would set Access-Control-Allow-Methods if it is configured.

[sberyozkin]

Sorry @hamburml I meant, one needs to configure https://quarkus.io/guides/http-reference#quarkus-vertx-http-config-group-cors-cors-config_quarkus.http.cors.methods.
If it is Access-Control-Request-Method then it can't be used on its own as Access-Control-Allow-Methods - it needs to be checked against the allowed set of methods configured on the server

[sberyozkin]

@hamburml I did a typo in my previous comment, fixed it

[hamburml]

@sberyozkin I opened a draft pull request. Pls check if you have time #33185 I did not know how I add a working test inside CORSFilterTest. I would need to mock a vertx RoutingContext event and HttpServerRequest and HttpServerResponse and check the status code of HttpServerResponse after filter.handle(...) is done.

[hamburml]

#33185 is merged