Closed Bug 1833707 Opened 2 years ago Closed 2 years ago

CORS header ‘Access-Control-Allow-Origin’ does not match in v102

Categories

(Core :: Networking: HTTP, defect)

Firefox 102
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: vigneshchockalingam, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Attached image bugzilla.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Attempting to make a POST request to origin after the sequence of 307 redirect and OPTIONS requests. The issue seems to be specific to v102 (both regular and ESR versions) but works fine on older versions of Firefox and on v103 or later. I didn't notice any change in CORS behaviors listed in the changelog for the version releases, and this seems to have broken user experience suddenly.

Here's the sequence of requests as observed in v102:

  1. POST 307
Status 307
Temporary Redirect
Version HTTP/2
Transferred 1.10 KB (531 B size)
Referrer Policy strict-origin-when-cross-origin
Request Priority Highest

Request headers:

POST /50c5ac5a976b/_/verify HTTP/2
Host: 50c5ac5a976b.us-west-1.captcha-sdk.awswaf.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com/
Content-Type: application/json; charset=UTF-8
Origin: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com
Content-Length: 1962
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Sec-GPC: 1
TE: trailers

Response headers:

HTTP/2 307 Temporary Redirect
server: CloudFront
date: Wed, 17 May 2023 18:09:50 GMT
content-length: 0
location: https://50c5ac5a976b.ffe3f3d2.us-west-1.captcha.awswaf.com/50c5ac5a976b/_/verify
cache-control: max-age=86400
access-control-allow-origin: *
access-control-allow-methods: *
access-control-allow-headers: *
access-control-max-age: 86400
x-cache: FunctionGeneratedResponse from cloudfront
via: 1.1 9ec40c03108c6895c219a0796de727be.cloudfront.net (CloudFront)
x-amz-cf-pop: HIO50-C2
x-amz-cf-id: y5WyWWyRxQpY07rh5ebbNPYqjrdbb-YTNMbbDP399vzXWDFJg2LUSA==
X-Firefox-Spdy: h2

  1. OPTIONS 200OK

Referrer Policy strict-origin-when-cross-origin

Request headers:

OPTIONS /50c5ac5a976b/_/verify HTTP/2
Host: 50c5ac5a976b.ffe3f3d2.us-west-1.captcha.awswaf.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Referer: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com/
Origin: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Sec-GPC: 1
TE: trailers

Response headers:

HTTP/2 200 OK
content-length: 0
date: Wed, 17 May 2023 18:09:51 GMT
access-control-allow-headers: content-type
access-control-allow-methods: POST, GET
access-control-allow-origin: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com
x-cache: Miss from cloudfront
via: 1.1 000f4a2f631bace380a0afa747a82482.cloudfront.net (CloudFront)
x-amz-cf-pop: HIO50-C1
x-amz-cf-id: d3Zz3mHQWvIofSimiCLdgvahuO31NK2KpJXL1BdYb3X6JlEhSMvZ1Q==
X-Firefox-Spdy: h2

  1. POST 200OK
Status 200OK
Version HTTP/2
Transferred 1.01 KB (531 B size)
Referrer Policy strict-origin-when-cross-origin
Request Priority Highest

Request Headers:

POST /50c5ac5a976b/_/verify HTTP/2
Host: 50c5ac5a976b.ffe3f3d2.us-west-1.captcha.awswaf.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/json; charset=UTF-8
Content-Length: 1962
Origin: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com
Referer: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com/
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
Sec-GPC: 1
TE: trailers

Response headers:

HTTP/2 200 OK
content-type: application/json
content-length: 531
date: Wed, 17 May 2023 18:09:51 GMT
access-control-allow-origin: https://d02t2enx6e.execute-api.us-west-1.amazonaws.com
x-amzn-waf-captcha-id: Root=1-6465186f-0f218a924614cde60fb6fd85
cache-control: no-cache
x-cache: Miss from cloudfront
via: 1.1 000f4a2f631bace380a0afa747a82482.cloudfront.net (CloudFront)
x-amz-cf-pop: HIO50-C1
x-amz-cf-id: 4KqtlDxtGFDepTSslfPklUtlNrZ3wyTf9ohge6x6Ig8y4HBscxRdmw==
X-Firefox-Spdy: h2

Actual results:

Observation in v102 is that both the POST requests fail with reason: CORS Allow Origin Not Matching Origin.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://50c5ac5a976b.ffe3f3d2.us-west-1.captcha.awswaf.com/50c5ac5a976b/_/verify. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘https://d02t2enx6e.execute-api.us-west-1.amazonaws.com’).

This is kinda odd because the Origin actually matches the access-control-allow-origin header, see the attached screenshot for comparison. This happens despite all extensions being disabled, so my reason of suspect is that it had to be a core change in how Firefox interprets the CORS headers.

Expected results:

Upon comparison of the same request pattern with other versions of Firefox:
In earlier versions of firefox, the ultimate POST request after the sequence of 307 and OPTIONS requests includes the proper origin. In 103 and later, it's the value null. The null Origin seems to have no issues, where Firefox v102 appears to have trouble when comparing when a proper Origin header value is supplied.

I'm seeking help in understanding this behavior and if it's a bug specific to Firefox v102 which went undocumented? Please also suggest any possible resolutions.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking: HTTP
Product: Firefox → Core

You could use https://mozilla.github.io/mozregression/ to find out what fixed things in 103 and then request that fix be added to the next minor version of the current ESR. Or you could just wait for the next major ESR release (2023-07-04) given that it's fixed in 103.

Thank you for the suggestion Robert, I was able to narrow down the fix to this commit: https://phabricator.services.mozilla.com/D147091, which aligns with the behavior we're observing in the correct Firefox versions. Can this patch be merged into the next minor revision of the current ESR?

You could try asking in that bug but there are regressions with that fix so patches for the regression bugs might need to go into the ESR too, that may be just too much risk for the ESR to take.

Flags: needinfo?(tschuster)
See Also: → 1605305

I don't think we should uplift this patch at all at this point. The Origin behavior is quite complicated and I think we had some followup work.

Flags: needinfo?(tschuster)

Hey Tom,
Based on your comments, I propose to resolve this as WONTFIX as it is too risky to be uplifted now.
Please let me know if you disagree?

Flags: needinfo?(tschuster)
Whiteboard: [necko-triaged]

Sorry, no, I don't think we should uplift this. We had some compatibility issues with the redirect tainting especially and that code was changed recently in bug 1817980 and bug 1800990.

The next ESR 115 is supposed to release at the beginning of July, hopefully that is an acceptable time frame.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(tschuster)
Resolution: --- → WONTFIX

Alright, it's a bit prolonged impact but we'll find a workaround - thanks for the consideration!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: