Since you have mentioned that CORS is already configured on your S3 bucket and the issue is intermittent, I would like to inform you that generally the error occurs when response to the CORS request is missing the required Access-Control-Allow-Origin header, which is used to determine whether or not the resource can be accessed by requesting origin. I would recommend you to refer to the following documents to learn about CORS:-
You can use CURL command to confirm if response headers for the request to get an object from S3 returned the Access-Control-Allow-Origin header:-
Let “Origin“ header be ”https://example.com“
$ curl -IvL "https://presigned-URLAmz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=SOMETHING/20220510/us-east-1/s3/aws4_request&X-Amz-Date=SOMETHINGT055847Z&X-Amz-SignedHeaders=host&X-Amz-Signature=SOMETHING" -H "Origin:https://example.com"
Connected to bucket.s3.amazonaws.com (220.127.116.11) port 443 (#0) //// TLS LOGS REMOVED
Host: bucket.s3.amazonaws.com User-Agent: curl/7.79.1 Accept: / Origin:https://example.com
- Mark bundle as not supporting multiuse < HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request < Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Origin: https://example.com < Access-Control-Allow-Methods: POST, GET, PUT, HEAD Access-Control-Allow-Methods: POST, GET, PUT, HEAD < Access-Control-Allow-Credentials: true Access-Control-Allow-Credentials: true < Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
It can be observed from the above output that S3 is returning 'Access-Control-Allow-Origin' header.
There are two possibilities for the intermittent error seen at your end:
- Your application is not always making CORS requsest and hence S3 is not identifying the request as a CORS request. Please know that if the "Origin" header is missing in the request, Amazon S3 doesn't treat the request as a cross-origin request, and doesn't send CORS response headers in the response. Please ensure that you are passing the Origin header in the request.
Example (same curl command but without specifying origin header, notice absence of Access-Control-Allow-Origin header in response):
curl -IvL "https://presigned-URLAmz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=SOMETHING/20220510/us-east-1/s3/aws4_request&X-Amz-Date=SOMETHINGT055847Z&X-Amz-SignedHeaders=host&X-Amz-Signature=SOMETHING"
- Trying 18.104.22.168:443...
- Connected to bucket.s3.amazonaws.com (22.214.171.124) port 443 (#0)
- /// removing TLS handshake
Host: bucket.s3.amazonaws.com User-Agent: curl/7.79.1 Accept: /
- Mark bundle as not supporting multiuse < HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request < Content-Type: application/xml Content-Type: application/xml < Server: AmazonS3 Server: AmazonS3 < Connection: close Connection: close
- I would like to inform you that Chrome intermittently gives a CORS mismatch error even though all the CORS settings are correct on S3 bucket and the request is a CORS request. However, this error is not observed on other browsers such as Firefox and Edge for the same requests. This is due to the following reasons.
S3: S3 only returns CORS headers for requests that contain the Origin headers. It does not send CORS headers or a 'Vary: Origin' header if the request is non-CORS. This implementation of S3 CORS is different from other CORS implementations as "Vary: Origin" header is usually sent for a Non-CORS request also.
Chrome (in some cases, Chromium based browsers) only has a single cache for XHR and other requests whereas other browsers such as Firefox and Edge has separate caches for XHR and other requests. When a request is sent to S3 without an Origin header, it'll respond without CORS headers or the Vary header. This response will be cached by Chrome. When a subsequent request is sent with the Origin header, Chrome will send a cached response which will lead to a CORS error. The other browsers do not show this behavior as they have separate caches. Please refer to the below threads which discuss about this issue with Chrome browser (in some cases, Chromium based browsers):-
As a workaround, you can change object metadata and check if this resolves your issue:
Set the 'Cache-Control: no-cache' metadata on the object in S3. This will make Google Chrome not cache your data.
[+] Editing object metadata in the Amazon S3 console - https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html [+] Working with object metadata - https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html
I recommend raising a technical support case along with a HAR capture if the issue is still not resolved so that we can look at the specific details and troubleshoot further.
I have the same issues too. with my react app, I did all of that fixes mentioned here:
We are experiencing intermittent errors. 30%-40% of uploads gets stuck with either 400 Bad Request or CORS Access to XMLHttpRequest has been blocked by CORS error. Most do get uploaded with the biggest file I uploaded so far was 7GB, Although I tried to remediate all possible fix I can find a way to bring the number of stuck uploads to 0.
Couple of the same issues posted most are related to Chrome, but I do experience the issue on Safari and Firefox albeit less often than Chrome.
I'm having CORS issues intermittently with video streams I host on S3 with a CloudFront. It seems that sometimes the first request to the file will fail with a CORS error even though I've setup the CORS headers in the S3 bucket to allow from any other domain. My file is hosted on the domain https://cdn.mapmyphotos.net and my website is hosted on https://www.mapmyphotos.net. It seems that eventually it will work (maybe after 1-2 days, maybe because the first request that was cached is invalidated). Sometimes it will work first time. I just tried with a recent video I published using my app (haha it was from an AWS Cloud Day today here in Melbourne Australia) and it failed with a CORS error on Firefox. I used cURL as suggested above and it did indeed have the right headers and was a 200 OK (I used a different origin to cdn.mapmyphotos.net).
Note: the files that are failing are videos steams hosted in S3. Other files like photos have worked from day one. I'm using VideoJS on the client to play the video streams.
Here's the cURL that I got from Firefox. This is from the request that failed in Firefox.
curl 'https://cdn.mapmyphotos.net/UserFiles/55686ae31ea8dcaf128b4572/livestreams/64c9dbcb9940607ecf4331b7/final_ff267fcf-0f91-4562-9357-ed6eb2da2706.m3u8' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0' -H 'Accept: /' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Origin: https://www.mapmyphotos.net' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-site' -H 'If-Modified-Since: Wed, 02 Aug 2023 04:36:05 GMT' -H 'If-None-Match: "39d35bee4024ec652e7a5edbe95d8486"' -H 'TE: trailers'
Interestingly, after running the cURL commands from the terminal and then refreshing the browser, it's no longer failing with CORS errors. It seems like the first erroneous request is cached, with that cached result eventually being invalidated and the video eventually working OK. Maybe running the cURL commands somehow invalidated that cache and now it works.
I just changed all my video URLs so the client goes direct to the S3 bucket instead of going through CloudFront and they're all working 100% so I suspect it's related to CloudFront somehow.
I'm having same issue with Angular app deployed on Amplify. This question and first answer in stack overflow suggest that the solution might be to add the following header to all of responses that support CORS
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
I tried it, not sure if it worked yet because the error is intermittent and only happens to a few users.
- asked 10 months ago
- Accepted Answerasked 22 days ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated a year ago
- Why am I getting the error "Invalid principal in policy" when I try to update my Amazon S3 bucket policy?AWS OFFICIALUpdated 9 months ago