Develop Reference

CORS Issue on Chrome Browser [duplicate]

I have an application (React SPA) that calls a bunch of servers on different subdomains of the application domain, i.e.:
the web app sits at foo.bar.com,
and talks to api.foo.bar.com and media.foo.bar.com.
When accessing api.foo.bar.com, I get an error from the browser (be it Edge, Chrome, or Firefox) telling me that the origin (foo.bar.com) is different from the value of the Access-Control-Allow-Origin response header. However, by inspection of the response, they are the same:
(I unfortunately have to obfuscate the address.)
Those apps are hosted on Kubernetes; the ingress is NGINX, and it's is not providing CORS (cors-enabled annotation is false). Both applications (api and media) are Express apps, and both have the same CORS configuration allowing the specific origin.
I'm wondering if this has something to do with the redirect - the call to the media... endpoint returns a redirect (302) whose Location is a api... address.
Other than that, I have no clue what could be wrong. Something is, for sure, because all browsers agree that my request should be blocked (on account of the origin).
In all cases, I've checked the address multiple times for typos, ending forward-slashes, etc. I've called OPTIONS on those endpoints with cURL and Postman, using all headers or just a few. They always answer the correct address.
Additional information, as requested:
Preflight request:
OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: feedurl
Referer: https://aiXXXXXXXXXXXXXXXX.com/
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Preflight response:
HTTP/2 204 No Content
date: Fri, 08 Oct 2021 13:33:10 GMT
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXXXX.com
vary: Origin
access-control-allow-credentials: true
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-headers: Content-Type, feedUrl
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
Request
The preflight passes, and the browsers starts a "flight" request:
GET /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
feedUrl: https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Referer: https://aiXXXXXXXXXXXXXXXXX.com/
Cookie: ory_kratos_session=MTYzMzYzODY1OHxEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiXXXXXXXXXXXXYVc1bkRDSUFJSHBtUWxsaWFsVlJhWGRTVGxSMmIzZHRkbTFqYm5CUlRWVkdkelpPWkRoWnXXXTyqwgK-0Pe0qtZHjNhfU-YoASjg3istMZi672swQ==
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Response
HTTP/2 302 Found
date: Fri, 08 Oct 2021 13:33:10 GMT
content-type: text/plain; charset=utf-8
content-length: 129
location: https://api.aiXXXXXXXXXXXXXXXXXX.com/media/1.0.0/hls/streams/19dd149d-f551-4093-b2aa-e5558388d545/hls.m3u8
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXX.com
vary: Origin, Accept
access-control-allow-credentials: true
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
At this response, the browser fails saying that the origin don't match the access-control-allow-origin.
(the first image was from Edge, since the log was more clear; this log is from Firefox)

Problem
The error message—I'm using dummy URLs and origins below—from the browser can be a bit confusing:
Access to XMLHttpRequest at 'https://api.example.com/' (redirected from 'https://media.example.com/') from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://example.com' that is not equal to the supplied origin.
The key here is that, as sideshowbarker hinted at in his comment, because your first preflighted request to https://media.example.com/ responds with a cross-origin redirect to https://api.example.com/, the browser performs another whole CORS access-control check for that resource. However, because the redirect resulting from the first preflighted request happens to be cross-origin, the browser sets the origin of the second preflight request (which the error message refers to as the "supplied origin"), not as https://example.com, but as the null origin!
Here's a rundown of what is likely happening:
Because https://api.example.com likely doesn't (and shouldn't!) allow the null, the second access-control check fails and you get that annoying CORS error.
Solution
Resist the temptation to allow the null origin on https://api.example.com/, as doing so has serious security ramifications: it amount to voiding the protection that the Same-Origin Policy provides.
Instead, you should get rid of that redirect from https://media.example.com/ to https://api.example.com/ and make your frontend request the https://api.example.com/ resource directly.
Alternatively, if you cannot completely get rid of the redirect but you can change its destination, make it a same-origin redirect (from somewhere https://media.example.org to elsewhere on https://media.example.org).

MP3 file's duration infinity in desktop / iOS SAFARI

I am trying to play this audio file in a native html5 audio tag. IN DESKTOP SAFARI / iOS SAFARI
here is the link to the file: https://primetime.a.bluejeans.com/a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3
Now, it has a couple of issues:
The duration is INFINITY ( checked after loadedmetadata event, and also after every timeupdate.
The audio doesn't play fully, it stops abruptly with NO errors at random times, ex at 50th second / 72nd second. the last event in this case is timeupdate only.
Html5 media tag's controls show "Live Broadcast". ( in the UI I mean )
below are the request and responses recorded from Charles (2 requests/responses):
REQUEST 1:
GET /a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3 HTTP/1.1
Host: primetime.a.bluejeans.com
Accept-Language: en-us
X-Playback-Session-Id: 174A3981-F3E3-4F49-A17B-BEBE88764552
Icy-Metadata: 1
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://fiddle.jshell.net/
Accept-Encoding: identity
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
RESPONSE 1 (showing only header):
HTTP/1.1 200 OK
x-amz-id-2: l4souPN96kHUVyThsqJZHllkVN873tbsPwk80hq94cixXcRKl3CTdO6HS32AbutMLInBSOXAZe8=
x-amz-request-id: 4122A053E2768F35
x-amz-replication-status: COMPLETED
x-amz-version-id: jAKAQ6MTbVed.NthIiH9ZOoLEWHRC95Z
Content-Type: audio/mpeg
Server: AmazonS3
Vary: Accept-Encoding
Date: Wed, 25 Nov 2020 16:43:00 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Referrer-Policy: strict-origin-when-cross-origin
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=86400 ; includeSubDomains ; preload
Expires: 0
Cache-Control: no-cache
REQUEST 2:
GET /a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3 HTTP/1.1
Host: primetime.a.bluejeans.com
Accept-Language: en-us
X-Playback-Session-Id: 174A3981-F3E3-4F49-A17B-BEBE88764552
Icy-Metadata: 1
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://fiddle.jshell.net/
Accept-Encoding: identity
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
RESPONSE 2:
HTTP/1.1 200 OK
x-amz-id-2: l4souPN96kHUVyThsqJZHllkVN873tbsPwk80hq94cixXcRKl3CTdO6HS32AbutMLInBSOXAZe8=
x-amz-request-id: 4122A053E2768F35
x-amz-replication-status: COMPLETED
x-amz-version-id: jAKAQ6MTbVed.NthIiH9ZOoLEWHRC95Z
Content-Type: audio/mpeg
Server: AmazonS3
Vary: Accept-Encoding
Date: Wed, 25 Nov 2020 16:43:00 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Referrer-Policy: strict-origin-when-cross-origin
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=86400 ; includeSubDomains ; preload
Expires: 0
Cache-Control: no-cache
CHECK OUT THE ISSUE LIVE: https://jsfiddle.net/y7whr25a/2/
Also please note that I have tried many answers from the web such as checking if server supports Range Requests (yes it does) and adding Range / Content Length / Accepted Ranges / 206 http response code By rewriting request/response in Charles but nothing worked, I'm about to lose all hope.
here is the same file but hosted on google drive, THIS WORKS IDK HOW: https://drive.google.com/u/1/uc?id=1b6UcqEb5_opUIR2eLzMghtAIQGYV2q8f&export=download

Your file is not properly built and misses metadata information telling the duration.
You should reencode it properly if you want it to work everywhere.
Chrome and Firefox (actually ffmpeg) are able to estimate this duration from the bitrate, but even then, it may be inacccurate.
But the problem with Safari is that your server doesn't accept Range requests. Somehow, Safari switches to stream player in this case.
One way to make this browser be able to read this file entirely without changing the server config is to first fetch it entirely as a Blob, and to generate a blob:// URI from there:
(async () => {
const src = "https://primetime.a.bluejeans.com/a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3";
const blob = await fetch( src )
.then( (resp) => resp.blob() );
const audio = new Audio( URL.createObjectURL( blob ) );
audio.controls = true;
document.body.append( audio );
audio.addEventListener( "loadedmetadata", (evt) =>
console.log( audio.duration )
);
})();

Sending cookie with request from subdomain

We have the following configuration:
testing.parentdomain.com
When you access this domain and create a basket we create a cookie stored for the basket value. The cookie domain is set to .testing.parentdomain.com, it is Httponly and has a path of /
We have a subdomain to the above which would like to access the cookie. subdomain.testing.parentdomain.com
This sub domain makes a call to an endpoint on the parent domain such as: testing.parentdomain.com/basketData. This call is a GET request that returns JSON.
Issue
The issue is that the subdomain does not appear to send the cookie value when making the request and therefore we do not get the expected response.
Attempts
Looking at other questions we have tried CORS and credential changes.
As an additional note, we bundle the below JS with webpack/babel.
Our request is from AJAX as follows:
$.ajax({
url: url,
type: 'GET',
xhrFields: {
withCredentials: true
},
crossDomain: true
})
The server is setup with CORS for the subdomain and allow-crendtials. In the response we can see these are returned.
access-control-allow-credentials: true
access-control-allow-origin: subdomain from above
Is there any reason that the cookie is not sent with the request to the parent domain? We have logged out the cookies on the server side response and they are not there as we expect.
Request Headers
:authority: testing.parentdomain.com
:method: GET
:path: /basket/data/
:scheme: https
accept: /
accept-encoding: gzip, deflate, br
accept-language: en-GB,en;q=0.9,en-US;q=0.8
origin: https://subdomain.testing.parentdomain.com
referer: https://subdomain.testing.parentdomain.com/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Response Headers
access-control-allow-credentials: true
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD, OPTIONS
access-control-allow-origin: https://subdomain.testing.parentdomain.com
cache-control: no-cache, no-store
content-length: 2238
content-type: application/json; charset=utf-8
date: Tue, 03 Nov 2020 20:39:36 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
set-cookie: AWSALB=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/
set-cookie: AWSALBCORS=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/; SameSite=None; Secure
status: 200
strict-transport-security: max-age=31536000;
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-robots-tag: noindex
x-ua-compatible: IE=edge
x-xss-protection: 1; mode=block

Even if you are calling the main domain from a subdomain, this is considered a cross-origin request.
Quote from the RFC 6454 which qualifies the "Origin" term:
Q: Why use the fully qualified host name instead of just the "top-
level" domain?
A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, at
many educational institutions, students can host content at
https://example.edu/~student/, but that does not mean a document
authored by a student should be part of the same origin (i.e.,
inhabit the same protection domain) as a web application for managing
grades hosted at https://grades.example.edu/.
So all of the things you did are indeed required to make it work:
access-control-allow-credentials: true
access-control-allow-origin: subdomain.testing.parentdomain.com (not a wildcard)
withCredentials: true in the request
The SameSite=None cookie attribute is not required in this case because a request from a subdomain to another subdomain of the same domain is considered "same site" (Source).
So just check that everything is correctly set, it should work as is.

At beginning of your question you stated:
The cookie domain is set to .testing.parentdomain.com
but in the logged server response:
set-cookie: AWSALBCORS=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/; SameSite=None; Secure
the Domain=.testing.parentdomain.com; parameter is clearly missing.
I don't know which programming language you are using to set the cookie, but I strongly suggest you to check the call you use to set the cookie in your server response.

JavaScript cross-domain request succeeds but data is filtered out

I have some working JavaScript (running inside Firefox (v41)) which I need to modify to support cross-domain XMLHttpRequests (my POST requests retrieve JSON encoded data). I have control over the server in question, so I capture OPTIONS requests and reply with:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Max-Age: 86400
The browser then correctly sends the POST request, my server responds with the data and that data arrives back at my machine; I can see it in Wireshark and it is well formed JSON.
HOWEVER, the data doesn't get to my JavaScript. I can see in the Firefox window that the response to the POST request does arrive, with all the expected headers indicating (for example) 1120 bytes of content but, when I click on the "Response" tab, there is nothing in it: SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data. My JavaScript code ends up in the XMLHttpRequest's onerror function.
What do I need to do to get my data correctly? Any advice welcomed.
Here is a sample of one complete HTTP exchange, as seen by Wireshark on the browser machine:
OPTIONS /getAllData HTTP/1.1
Host: blah:blah
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: null
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 86400
Date: Fri, 26 Aug 2016 09:22:14 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8
test
POST /getAllData HTTP/1.1
Host: blah:blah
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/string; charset=UTF-8
Content-Length: 4
Origin: null
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Fri, 26 Aug 2016 09:22:15 GMT
Content-Length: 1121
{"wellformed":"data 1121 bytes long"}

I have toyed with Access-Control-Allow-Origin and the header needs to be implemented in each and every response that is sent to the client.
So, whenever you make that POST, the answer MUST include the ACAO header otherwise the browser will filter out the content for security purposes. I do not see the header from the capture you made, which might explain the issue.
You can take a look at the examples from Mozilla, you will see that the response to the POST do include the ACAO header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Also, it seems that your body content is not separated from the header by a conventional empty line (\r\n in HTTP protocol). The body seems to be part of the header in your pastes, but it might just be a glitch from your copy-paste. If it's not then it's also a potential explanation: no body = no content.
Finally, I recommend that you debug your trafic through a tool such as BurpSuite which implements a nice Proxy allowing you not only to real-time view and edit your requests, but also to replay them and toy around. Initially a security tool, it is still great for debugging web apps.
https://portswigger.net/burp/

is this some cross domain issue?

I am not an expert on fiddler but trying to figure out what is wrong with my configuration.
I have a website on domain example.com which i am hosting on an iframe on another site which is on domain example.org.
example.com has login controls and on successful authentication i have to open a new tab. Chrome and Firefox are working fine, but IE behaves as if i clicked refresh button on Login click.
Traced with Fiddler, but i am not sure what should i be looking looking out for, please help.
Request Header:
POST https://example.com/Login/VerifyUserDetails HTTP/1.1 Accept: application/json, text/javascript, */*; q=0.01 Content-Type: application/json X-Requested-With: XMLHttpRequest Referer: https://example.com/ Accept-Language: en-US Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Host: example.com Content-Length: 37 DNT: 1 Connection: Keep-Alive Cache-Control: no-cache
{"userEmail":"abc#gmail.com"}
Response Header:
HTTP/1.1 200 OK Cache-Control: public, no-store, max-age=0 Content-Length: 65 Content-Type: application/json; charset=utf-8 Expires: Wed, 29 Jun 2016 00:07:28 GMT Last-Modified: Wed, 29 Jun 2016 00:07:28 GMT Vary: * Server: Microsoft-IIS/7.5 X-UA-Compatible: IE=Edge X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: frame-ancestors 'self' https://example.org*.example.com *.example.org; X-Powered-By: ARR/2.5 X-Powered-By: ASP.NET Date: Wed, 29 Jun 2016 00:07:38 GMT
{"IsADUser":false,"IsActiveUser":false,"PasswordSetError":""}
Please guide.
Although i think someone with expertise on this might find this interesting that the immediate next call after authentication is a redirect to which i see below response:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>

Turns out I need to add the domain that I am hosting in the iframe in IE trusted sites. It works. :) So, it was not a cross domain scripting issue, I am using the w3c recommended content security policy.

Just to add to it, I had to add p3p policy to the site. I had the domain in my IE trusted site list so it worked for me with above solution. But, one external user didn't have our domain in whitelist and he kept getting 401 errors.
I searched a lot and have to add a valid p3p token for it to work. Not any p3p policy, but a valid one unlike other suggestions that I found on the net.