CORS problems with Amazon S3 on the latest Chomium and Google Canary

google-chrome amazon-web-services amazon-s3 cors

12,352

Solution 1

Add any query parameter such as ?cacheblock=true to the url, like so:

Instead of: https://somebucket.s3.amazonaws.com/someresource.pdf

do: https://somebucket.s3.amazonaws.com/someresource.pdf?cacheblock=true

The technical explanation I don't have entirely down. But it is something like the following:

Including a query parameter will prevent the 'misbehaving' caching behavior in Chrome, causing Chrome to send out a fresh request for both the preflight request and the actual request, allowing the proper headers to be present on both requests, allowing S3 to respond properly. Approximately.

Solution 2

Amazon released a fix for this a few months back. We were seeing the errors in current versions of Chrome & Safari (did not check Firefox). For anyone still running into this problem, try the following configuration:

S3 bucket CORS policy:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
  </CORSRule>
</CORSConfiguration>

CloudFront distribution settings (Behavior tab):

Allowed HTTP Methods: GET, HEAD, OPTIONS
Forward headers: Whitelist
Whitelist headers: Origin, Access-Control-Request-Headers, Access-Control-Request-Method

We are hosting css and static javascript files via CloudFront with an S3 origin. We reference our javascript files via <script crossorigin="anonymous" src="http://assets.domain.com/app.js">.

EDIT

We began seeing this issue again with Safari 10.1.2. It turns out that we were accessing the Javascript file in two ways...

On page A via <script crossorigin="anonymous" src="http://assets.domain.com/app.js">. On page B via $.ajax() (so that it was lazy loaded).

If you went to page A -> page B -> page A, we would get a cross origin denied error. We took out the lazy loading approach and it solved our issue (again).

Solution 3

In all likelihood, you're running into a very well-known problem with S3/CloudFront/CORS. The best solution I've been able to find is to have an app that proxies between S3 and CloudFront, always adding the appropriate CORS headers to the objects as they come back.

S3 + CloudFront are broken when it comes to serving CORS assets to different web browsers. The issue is two-fold.

Not all browsers require CORS for web fonts and other static assets. If one of these browsers makes the request, S3 won't send the CORS headers, and CloudFront will cache the (unhelpful) response.
CloudFront doesn't support the Vary: Origin header, so it has issues with using * for the AllowedOrigin value, and will only cache the first of multiple AllowedOrigin values.

In the end, these two issues make S3 + CloudFront an untenable solution for using CORS with a (fast) CDN solution — at least, out of the box. The bulletproof solution is to create a simple app that proxies the requests between S3 and CloudFront, always adding the requisite CORS headers so that CloudFront always caches them.

Request against a “Cold” cache

← Browser requests a static asset from CloudFront.
← CloudFront misses, and hits its origin server (a Proxy App).
← The Proxy App passes the request to S3.
→ S3 responds back to the Proxy App.
→ The Proxy App adds the correct CORS headers (whether S3 had sent them or not). The Proxy App responds back to CloudFront.
→ CloudFront caches the result and responds back to the browser.

Request against a “Warm” cache

← Browser requests a static asset from CloudFront.
→ CloudFront hits, and responds back to the browser.

Yes, this is a well-known, widespread issue:

I can say that our S3 and CloudFront teams are well-aware of the issues discussed here. By writing up a simple app that can act as a proxy between S3 and CloudFront, you can manually inject all of the correct CORS response headers before CloudFront caches them.

If you always work in Firefox, then you likely won't notice the issue — CloudFront will always be caching your CORS-enabled responses. If you work primarily in Safari or Chrome, you'll see it much more often when you switch back to a browser which requires these headers (Firefox and IE). Also, if you have separate development/staging/production environments, you're likely to run into the multi-origin issues more often.

Solution 4

Wanted to chime in with an alternate theory to this old question: Chrome has a bug/"feature" that's been present since at least Aug 2014 that causes a cross-origin request to fail if the resource was first loaded via a normal fetch, apparently because Chrome caches the CORS-less resource headers and then refuses to give the cached resource to the cross-origin request.

To make matters worse in our testing in a complex scenario, it isn't even necessarily fully consistent between refreshes (because order of resource loading?) and other browsers don't appear to share the behavior.

It was fun bug hunt! It seems that simply adding crossorigin='anonymous' to any tags loading the resource forces Chrome to pull the CORS headers in, fixing the subsequent cross-origin requests.

View more solutions

12,352

Chris Cinelli

Currently working for BloomBoard, a startup that helps teachers to become better teachers.

Updated on June 17, 2022

Comments

Chris Cinelli almost 2 years
Our website is having problems loading CSS and JS resources on a Amazon S3 bucket with the very latest version of Chromium (Version 33.0.1722.0 - 237596) and Chrome Canary. It works well with any of the other browsers including the current Chrome (31.0.1650.57).

The error is:

Script from origin 'https://mybucket.s3.amazonaws.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://app.example.com' is therefore not allowed access.

Our S3 CORS configuration on the resource bucket is:
```
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>300000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>
```
Is it a bug with Chromium? Did something change on the latest CORS spec?
Chris Cinelli over 10 years

Where is this "well-known problem with S3/CloudFront/CORS" documented? And why it works fine in the current Chrome and not in Chrome Canary?
Ryan Parman over 10 years

The spec says that web fonts are supposed to use CORS. So far, IE and Firefox are the only ones that implement the spec. Safari, Chrome and Opera do not. It's probable that Chrome (and in-turn Opera) are changing their implementation to follow the spec.
Chris Cinelli over 10 years

current version of Firefox does not have problems.
Ryan Parman over 10 years

It very much does. Need more space to explain, so see my follow-up answer.
Chris Cinelli over 10 years

This is good stuff. Regarding my question: (1) We do not use CloudFront. (2) Our page works on the current version of Chrome and Firefox. Not on the latest. (3) I field a bug on Chromium and they are currently looking at it. It may be a regression problem.
Bjorn over 10 years

If you write a proxy you give up on the CDN benefits of cloudfront.
Ryan Parman over 10 years

@Bjorn Tipling: Please re-read the flow I discussed before commenting. The proxy is on the source side, not the cached side. Once CloudFront caches the content in its CDN, it's cached, causing no issues with how a CDN works.
chchrist almost 10 years

@RyanParman You mentioned that some browsers don't require CORS. Do you know which ones?
Ryan Parman almost 10 years

At present, Safari and Chrome do not enforce CORS on web fonts. Firefox and (modern) Internet Explorer do.
Eamonn Gahan over 9 years

I've put in an answer on a similar question where I've Cloudfront and CORS working without a query string hack: stackoverflow.com/questions/12229844/…
Chris Scott over 8 years

this makes sense but do you have to wait for it to propagate? if so, how long? I know there is a setting for default TTL which is 24 hours (by default), is that the amount of time you need to wait for this change to take effect?
dignoe over 8 years

You just have to wait for the Cloudfront distribution settings to propagate to all of the edge servers. Took us 15-20 mins to be back online.
Marc Stober over 8 years

I know this discussion was a while ago, but the original question asked about scripts, not web fonts. I've just run into that. I'd always though script tags were exempt from this rule (and that's why JSONP was popular as a workaround to browser restrictions). Are script tags now subject to this, does this mean JSONP doesn't work now, and is there documentation on this somewhere I can't seem to find?
John Rey M. Baylen over 5 years

This answer help me a lot :) Thank you so much :) I upvote your answer :D
nassan almost 4 years

Right @AnujTBE, the main idea here is that there should be some sort of query paramater
Daniel Facciabene over 3 years

This pointed me in the right direction. In my case I was using an OBJECT tag to load a PDF file for the first time, so the crossorigin attribute was not available. So before setting the PDF url to the OBJECT, I fetched the PDF with a regular ajax request. That solved my problem.
brad over 3 years

Thank you. I searched for hours to solve an issue setting a canvas background with XMLHttpRequest!
David Holada over 3 years

Thank you very much! I spent almost 2 hours by testing my app only to realize what is causing the problem. Now you also gave me the answer what is the source of this behavior. In my case this issue happened to me when I was loading one image twice. I needed the same image to be loaded into the 3D model as a texture and secondly as a 2D texture thumbnail.