CORS filter complains about "wrong" method on same-origin POST request

[bannmann]

Describe the bug

I run a Quarkus application on https://settings.example.com and an associated static web site on https://www.example.com.

Here's the CORS config:

quarkus.http.cors.enabled=true
quarkus.http.cors.origins=https://www.example.com
quarkus.http.cors.methods=GET
quarkus.http.cors.access-control-allow-credentials=true

Notice that I do not allow POST, PUT or DELETE requests via CORS.

The goal here is that the web site can GET certain data from the application despite that application having a different origin (settings subdomain vs www subdomain).

CORS works fine. The problem occurs when the user is on the settings subdomain and clicks a button to change something. This results in a same-origin POST request (see also this comment in #29542).

Expected behavior

After noticing that it's dealing with a same-origin request, io.quarkus.vertx.http.runtime.cors.CORSFilter should skip checking the method.

Actual behavior

1. io.quarkus.vertx.http.runtime.cors.CORSFilter detects that it's a same-origin request: isSameOrigin(request, origin) returns true.
2. The filter accepts the origin of the request, setting allowsOrigin to true.
3. The filter rejects this same-origin non-CORS request because POST is not allowed for CORS requests.

How to Reproduce?

I will try to write a reproducer as soon as I find the time.

Output of uname -a or ver

Microsoft Windows [Version 10.0.19045.6466]

Output of java -version

OpenJDK Runtime Environment Corretto-21.0.8.9.1 (build 21.0.8+9-LTS)

Quarkus version or git rev

3.30.2

Build tool (ie. output of mvnw --version or gradlew --version)

Maven 3.9.11

Additional information

Though the method check is what breaks my configuration, it's not only that: I suspect that all the logic about allowed headers and credentials also should not apply to same-origin non-CORS requests.

However, one should probably research that. The specs may or may not say something like "it's illegal / frowned upon / bandwidth wasting / harmless to return CORS-related response headers for non-CORS requests".

[quarkus-bot]

/cc @sberyozkin (bearer-token,jwt,security)

[michalvavrik]

I think what you describe in Actual behavior is clear enough. I had a look and I think it is clear how to reproduce that one and easy to fix. I also happen to agree that allowed HTTP methods should only apply on cross-origin requests, but I am not the author of this. I think we need to hear from @sberyozkin .

Though the method check is what breaks my configuration, it's not only that: I suspect that all the logic about allowed headers and credentials also should not apply to same-origin non-CORS requests.
However, one should probably research that. The specs may or may not say something like "it's illegal / frowned upon / bandwidth wasting / harmless to return CORS-related response headers for non-CORS requests".

I can't see anything specifying that these headers aren't allowed for the same-origin https://fetch.spec.whatwg.org/#http-responses. The way I understand it that, for example Access-Control-Allow-Methods specifies methods allowed for cross-origin requests, so the value is not incorrect as it does not apply to the same-origin request.

[sberyozkin]

I also happen to agree that allowed HTTP methods should only apply on cross-origin requests

Indeed, if the request has been recognized as the same origin request, that is as a non cross origin one, then CORS related restrictions should not apply.

[michalvavrik]

Cool, I'll fix that and we can deal (discuss) headers separately.