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

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.

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):

1. Allowed HTTP Methods: GET, HEAD, OPTIONS
2. Forward headers: Whitelist
3. 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).

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:

• https://forums.aws.amazon.com/message.jspa?messageID=445325
• https://forums.aws.amazon.com/thread.jspa?messageID=404768
• https://forums.aws.amazon.com/message.jspa?messageID=346287
• https://forums.aws.amazon.com/message.jspa?messageID=278230
• https://forums.aws.amazon.com/thread.jspa?messageID=388132
• https://twitter.com/kindofwater/status/350630880651395072
• Amazon S3 CORS (Cross-Origin Resource Sharing) and Firefox cross-domain font loading
• https://coderwall.com/p/ub8zug
• http://timwhitlock.info/blog/2012/09/web-fonts-on-amazon-s3/
• http://www.yodi.sg/solve-load-font-face-cloudfront-amazon-s3-and-firefox-ie-caused-by-cors-access-control-allow-origin/
• And many more!

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.