S3 not returning Access-Control-Allow-Origin headers?

Question

I am having trouble forcing S3 to set CORS headers on all of the objects it returns from a bucket, though CORS is enabled, as client-side S3 uploads is working, the returned objects do not have CORS headers!

The policy I have enabled is :

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

An example object URL https://s3.amazonaws.com/captionable/meme/test

Does anyone know what is wrong?

Answer 1

I also ran into this with an <image> tag, and after following Myrne Stol's answer I added the crossorigin=anonymous tag to my image tag. I verified that the Origin header was indeed being sent to S3, but still, the Access-Control-Allow-Origin header was not being sent in response.

I came across this SO answer and it solved it. I changed the AllowedOrigin in my S3 config to this:

<AllowedOrigin>http://*</AllowedOrigin> <AllowedOrigin>https://*</AllowedOrigin> 

and now S3 responds with the access headers. Yay!

Answer 2

First of all, make sure an Origin header with every request. If no Origin header is sent, S3 won't send access-control headers, as S3 deems them irrelevant (and typically, they are). A browser (for which the CORS mechanism is meant) will automatically send an Origin header when doing cross-origin HTTP requests through XMLHTTPRequest.

In case of loading images with img, you need to add crossorigin="anonymous" attribute. See MDN Documentation on crossorigin attribute. This will cause the browser to send an Origin request header like it does with XMLHTTPRequest.

Going by the answer of Sam Selikoff, you may need to change

 <AllowedOrigin>http://*</AllowedOrigin> 

to

 <AllowedOrigin>http://*</AllowedOrigin>  <AllowedOrigin>https://*</AllowedOrigin> 

I haven't tested this.

Going by Paul Draper's comment on this answer: Watch out for caching issues. A browser may use a cached response that did not include the appropriate Access-Control response headers. During development, you can clear your cache. In production, you must switch to a new URL for the resource, if it was used in a static manner before.