Cloudfront 403 ошибка

Resolution

The domain name isn’t associated with an alternate domain name (CNAME) on a distribution

If you create a Domain Name System (DNS) but don’t add a CNAME in your CloudFront distribution configuration, then CloudFront returns a 403 error. This occurs even if the CNAME is redirected towards CloudFront at the DNS level. 

To use a CNAME instead of the default CloudFront URL, follow the instructions for Adding an alternate domain name.

For more information, see Using custom URLs by adding alternate domain names (CNAMEs).

CloudFront geographic restrictions were configured on the distribution

CloudFront geographic restrictions can prevent users in specific countries from accessing your content. If geographic restrictions cause the error, then the 403 response contains a message similar to: «The Amazon CloudFront distribution is configured to block access from your country.» Also, the response header Server: CloudFront is present. The corresponding CloudFront access log entry contains ClientGeoBlocked as the value for x-edge-detailed-result-type.

For more information, see Restricting the geographic distribution of your content.

AWS WAF is configured on the CloudFront distribution and is blocking the request

If you use AWS WAF to monitor forwarded requests and the requested content doesn’t match the specified conditions, then the content is blocked by WAF. You receive a 403 error. In this case, the error contains a message similar to: «Request blocked. We can’t connect to the server for this app or website at this time.» The Server response header contains CloudFront as the value. The corresponding access log entry has Error as the value for x-edge-detailed-result-type. 

The same error message and a response header value of Cloudfront might be present when the reason the request is blocked isn’t AWS WAF.  To confirm that the request is blocked by AWS WAF and identify the rule that blocked it, check the AWS WAF logs for the blocked request. Or, check the AWS WAF CloudFront metrics for the relevant WebACL. Then, check the WebACL to see the rules that are blocked. For more information, see Testing and tuning your AWS WAF protections.

An Amazon S3 origin is returning a 403 error

Based on your Amazon Simple Storage Service (Amazon S3) as origin configuration, see the following for troubleshooting:

I’m using an S3 website endpoint as the origin of my CloudFront distribution. Why am I getting 403 Access Denied errors?

I’m using an S3 REST API endpoint as the origin of my CloudFront distribution. Why am I getting 403 Access Denied errors?

A custom origin is returning the 403 error

A 403 error can be returned by an origin due to an application firewall or other reason at the custom origin. If the response contains a Server header without the value CloudFront, then the error might be returned from the custom origin. 

To determine if the error is returned from the custom origin, check the origin HTTP access logs. 

If you’re not able to check the origin HTTP access logs, use the following troubleshooting methods:

• Check CloudFront access logs. If the time-taken field for the blocked request is significantly lesser than the average of the time-taken field, then the response might not have come from the origin. A low value in the time-taken field indicates that a response was sent from edge location.
• Make the request directly to the origin. If you can replicate the error without going through CloudFront, then the origin might be returning the 403 error.

The error is caused by a signed URL or signed cookies configuration

If you have Restrict viewer access turned on for your CloudFront’s behavior configuration, then requests made without using signed cookies or URL result in a 403 error.

For more information about configuring signed cookies and signed URLs, see Serving private content with signed URLs and signed cookies.

For troubleshooting steps, see How do I troubleshoot issues related to a signed URL or signed cookies in CloudFront?

The distribution with viewer protocol policy not configured for HTTP and HTTPS

If the HTTP request is sent to a distribution with Viewer Protocol Policy setting of HTTPS only, then the request can return a 403 error. 

For more information, see Requiring HTTPS for communication between viewers and CloudFront.

When restricting access to S3 content using a bucket policy that inspects the incoming Referer: header, you need to do a little bit of custom configuration to «outsmart» CloudFront.

It’s important to understand that CloudFront is designed to be a well-behaved cache. By «well-behaved,» I mean that CloudFront is designed to never return a response that differs from what the origin server would have returned. I’m sure you can see that is an important factor.

Let’s say I have a web server (not S3) behind CloudFront, and my web site is designed so that it returns different content based on an inspection of the Referer: header… or any other http request header, like User-Agent: for example. Depending on your browser, I might return different content. How would CloudFront know this, so that it would avoid serving a user the wrong version of a certain page?

The answer is, it wouldn’t be able to tell — it can’t know this. So, CloudFront’s solution is not to forward most request headers to my server at all. What my web server can’t see, it can’t react to, so the content I return cannot vary based on headers I don’t receive, which prevents CloudFront from caching and returning the wrong response, based on those headers. Web caches have an obligation to avoid returning the wrong cached content for a given page.

«But wait,» you object. «My site depends on the value from a certain header in order to determine how to respond.» Right, that makes sense… so we have to tell CloudFront this:

Instead of caching my pages based on just the requested path, I need you to also forward the Referer: or User-Agent: or one of several other headers as sent by the browser, and cache the response for use on other requests that include not only the same path, but also the same values for the extra header(s) that you forward to me.

However, when the origin server is S3, CloudFront doesn’t support forwarding most request headers, on the assumption that since static content is unlikely to vary, these headers would just cause it to cache multiple identical responses unnecessarily.

Your solution is not to tell CloudFront that you’re using S3 as the origin. Instead, configure your distribution to use a «custom» origin, and give it the hostname of the bucket to use as the origin server hostname.

Then, you can configure CloudFront to forward the Referer: header to the origin, and your S3 bucket policy that denies/allows requests based on that header will work as expected.

Well, almost as expected. This will lower your cache hit ratio somewhat, since now the cached pages will be cached based on path + referring page. It an S3 object is referenced by more than one of your site’s pages, CloudFront will cache a copy for each unique request. It sounds like a limitation, but really, it’s only an artifact of proper cache behavior — whatever gets forwarded to the back-end, almost all of it, must be used to determine whether that particular response is usable for servicing future requests.

See http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders for configuring CloudFront to whitelist specific headers to send to your origin server.

Important: don’t forward any headers you don’t need, since every variant request reduces your hit rate further. Particularly when using S3 as the back-end for a custom origin, do not forward the Host: header, because that is probably not going to do what you expect. Select the Referer: header here, and test. S3 should begin to see the header and react accordingly.

Note that when you removed your bucket policy for testing, CloudFront would have continued to serve the cached error page unless you flushed your cache by sending an invalidation request, which causes CloudFront to purge all cached pages matching the path pattern you specify, over the course of about 15 minutes. The easiest thing to do when experimenting is to just create a new CloudFront distribution with the new configuration, since there is no charge for the distributions themselves.

When viewing the response headers from CloudFront, note the X-Cache: (hit/miss) and Age: (how long ago this particular page was cached) responses. These are also useful in troubleshooting.

Update: @alexjs has made an important observation: instead of doing this using the bucket policy and forwarding the Referer: header to S3 for analysis — which will hurt your cache ratio to an extent that varies with the spread of resources over referring pages — you can use the new AWS Web Application Firewall service, which allows you to impose filtering rules against incoming requests to CloudFront, to allow or block requests based on string matching in request headers.

For this, you’d need to connect the distribution to S3 as as S3 origin (the normal configuration, contrary to what I proposed, in the solution above, with a «custom» origin) and use the built-in capability of CloudFront to authenticate back-end requests to S3 (so the bucket contents aren’t directly accessible if requested from S3 directly by a malicious actor).

See https://www.alexjs.eu/preventing-hotlinking-using-cloudfront-waf-and-referer-checking/ for more on this option.

Resolution

The domain name isn’t associated with an alternate domain name (CNAME) on a distribution

If you create a Domain Name System (DNS) but don’t add a CNAME in your CloudFront distribution configuration, then CloudFront returns a 403 error. This occurs even if the CNAME is redirected towards CloudFront at the DNS level. 

To use a CNAME instead of the default CloudFront URL, follow the instructions for Adding an alternate domain name.

For more information, see Using custom URLs by adding alternate domain names (CNAMEs).

CloudFront geographic restrictions were configured on the distribution

CloudFront geographic restrictions can prevent users in specific countries from accessing your content. If geographic restrictions cause the error, then the 403 response contains a message similar to: «The Amazon CloudFront distribution is configured to block access from your country.» Also, the response header Server: CloudFront is present. The corresponding CloudFront access log entry contains ClientGeoBlocked as the value for x-edge-detailed-result-type.

For more information, see Restricting the geographic distribution of your content.

AWS WAF is configured on the CloudFront distribution and is blocking the request

If you use AWS WAF to monitor forwarded requests and the requested content doesn’t match the specified conditions, then the content is blocked by WAF. You receive a 403 error. In this case, the error contains a message similar to: «Request blocked. We can’t connect to the server for this app or website at this time.» The Server response header contains CloudFront as the value. The corresponding access log entry has Error as the value for x-edge-detailed-result-type. 

The same error message and a response header value of Cloudfront might be present when the reason the request is blocked isn’t AWS WAF.  To confirm that the request is blocked by AWS WAF and identify the rule that blocked it, check the AWS WAF logs for the blocked request. Or, check the AWS WAF CloudFront metrics for the relevant WebACL. Then, check the WebACL to see the rules that are blocked. For more information, see Testing and tuning your AWS WAF protections.

An Amazon S3 origin is returning a 403 error

Based on your Amazon Simple Storage Service (Amazon S3) as origin configuration, see the following for troubleshooting:

I’m using an S3 website endpoint as the origin of my CloudFront distribution. Why am I getting 403 Access Denied errors?

I’m using an S3 REST API endpoint as the origin of my CloudFront distribution. Why am I getting 403 Access Denied errors?

A custom origin is returning the 403 error

A 403 error can be returned by an origin due to an application firewall or other reason at the custom origin. If the response contains a Server header without the value CloudFront, then the error might be returned from the custom origin. 

To determine if the error is returned from the custom origin, check the origin HTTP access logs. 

If you’re not able to check the origin HTTP access logs, use the following troubleshooting methods:

• Check CloudFront access logs. If the time-taken field for the blocked request is significantly lesser than the average of the time-taken field, then the response might not have come from the origin. A low value in the time-taken field indicates that a response was sent from edge location.
• Make the request directly to the origin. If you can replicate the error without going through CloudFront, then the origin might be returning the 403 error.

The error is caused by a signed URL or signed cookies configuration

If you have Restrict viewer access turned on for your CloudFront’s behavior configuration, then requests made without using signed cookies or URL result in a 403 error.

For more information about configuring signed cookies and signed URLs, see Serving private content with signed URLs and signed cookies.

For troubleshooting steps, see How do I troubleshoot issues related to a signed URL or signed cookies in CloudFront?

The distribution with viewer protocol policy not configured for HTTP and HTTPS

If the HTTP request is sent to a distribution with Viewer Protocol Policy setting of HTTPS only, then the request can return a 403 error. 

For more information, see Requiring HTTPS for communication between viewers and CloudFront.

Something is causing your files to be requested from CloudFront before they are present in the bucket. The default configuration of CloudFront causes this to be negatively-cached for up to 5 minutes.

By default, when your origin returns an HTTP 4xx or 5xx status code, CloudFront caches these error responses for five minutes and then submits the next request for the object to your origin to see whether the problem that caused the error has been resolved and the requested object is now available.

^{— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

If the browser, or anything else, tries to download the file from that particular CloudFront edge (or any edge, if the request happens to also go through the regional edge — CloudFront now has two edge layers) before the upload into S3 is complete, S3 will return an error, and CloudFront — at that edge location — will cache that error and remember, for the next 5 minutes, not to bother trying again.

This timer is configurable.

You can specify the error-caching duration—the Error Caching Minimum TTL—for each 4xx and 5xx status code that CloudFront caches. For a procedure, see Configuring Error Response Behavior.

^{— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

Set the value to 0 for any error codes, like 403, where you want to disable the error cache.

The content in this answer is adapted from my original post on Stack Overflow.