AWS S3 CORS 403 Error with OPTIONS Request

Question

I am trying to access an html file that is in S3 from an ajax request and I got a 403 error.

I read AWS online that if I do this, I need to set AWS CORS rules to fix 403 error.

However, I tried two days and I was out of luck. Here is my CORS configuration:

<?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> <ExposeHeader>XMLHttpRequest</ExposeHeader> <AllowedHeader>x-csrftoken</AllowedHeader> </CORSRule> </CORSConfiguration> 

And my HTTP request looks like this:

 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Access-Control-Request-He... x-csrftoken Access-Control-Request-Me... GET Connection keep-alive Host xxxxxxxxx.cloudfront.net Origin http://localhost:8000 User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 

Can someone help me see what I missed?

Thanks!

Answer 1

HTTP 403 (Frobidden) does not necessarily mean that you need CORS. One of the options is all requests to the cloud (of the same origin) and your distribution has several sources and behavior. Example:

 Beavior -> Origin /api/* -> my.api.com /static/* -> my.s3.bucket 

But if you really need cross-origin requests, CORS headers should be redirected to the cloud scope and have the same behavior. In your example, you probably want to be more solvable with the headers you allow ( <AllowedHeader>*</AllowedHeader> ?). But this will be more related to browser behavior than CLoudFront or S3.

Answer 2

For those who came here for 403 at the OPTIONS request of cross-access to s3 and did not find what they were looking for, maybe my experience in this can help.

tldr; browsers are designed to set the source to zero in 302 redirects from another source

I also ran into the CORS problem when pre-querying a resource from the recycle bin, a resource that was otherwise available when browsing directly.

I tuned CORS to a bucket with properly accepted headers and origins. Something like the following.

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

Then i got an error

 Access to XMLHttpRequest at 'https://[REDACTED].s3.amazonaws.com/[REDACTED]?AWSAccessKeyId=[REDACTED]' (redirected from '[REDACTED]') from origin 'null' has been blocked by CORS policy: Response to preflight request does not pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. 

After checking the request headers, it became clear that the only suspicious thing was Origin, which had the value "null".

 Access-Control-Request-Headers: authorization Access-Control-Request-Method: GET Origin: null Referer: [REDACTED] User-Agent: [REDACTED] 

As it turns out, browsers are designed to set the source to zero in 302 redirects from another source due to security issues. More details here .

There is no solution to this problem, except to not redirect. I had to redesign the server resource that was redirecting to provide a link for direct access to s3 bbject instead.