Troubleshooting CORS - Amazon Simple Storage Service
403 Forbidden error - CORS is not enabled for this bucket403 Forbidden error - This CORS request is not allowed Headers not found in CORS response Considerations of CORS on S3 proxy integrations

Troubleshooting CORS

The following topics can help you troubleshoot some common CORS issues related to S3.

403 Forbidden error: CORS is not enabled for this bucket

The following 403 Forbidden error occurs when a cross-origin request is sent to Amazon S3 but CORS is not configured on your S3 bucket.

Error: HTTP/1.1 403 Forbidden CORS Response: CORS is not enabled for this bucket.

The CORS configuration is a document or policy with rules that identify the origins that you will allow to access your bucket, the operations (HTTP methods) that you will support for each origin, and other operation-specific information. See how to configure CORS on S3 by using the Amazon S3 console, AWS SDKs, and REST API. For more information on CORS and examples of a CORS configuration, see Elements of CORS.

403 Forbidden error: This CORS request is not allowed

The following 403 Forbidden error is received when a CORS rule in your CORS configuration doesn't match the data in your request.

Error: HTTP/1.1 403 Forbidden CORS Response: This CORS request is not allowed.

As a result, this 403 Forbidden error can occur for multiple reasons:

  • Origin is not allowed.

  • Methods are not allowed.

  • Requested headers are not allowed.

For each request that Amazon S3 receives, you must have a CORS rule in your CORS configuration that matches the data in your request.

Origin is not allowed

The Origin header in a CORS request to your bucket must match the origins in the AllowedOrigins element in your CORS configuration. A wildcard character ("*") in the AllowedOrigins element would match all HTTP methods. For more information on how to update the AllowedOrigins element, see Configuring cross-origin resource sharing (CORS).

For example, if only the http://www.example1.com domain is included in the AllowedOrigins element, then a CORS request sent from the http://www.example2.com domain would receive the 403 Forbidden error.

The following example shows part of a CORS configuration that includes the http://www.example1.com domain in the AllowedOrigins element. 

"AllowedOrigins":[
   "http://www.example1.com"
]

For a CORS request sent from the http://www.example2.com domain to be successful, the http://www.example2.com domain should be included in the AllowedOrigins element of CORS configuration. 

"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]

Methods are not allowed

The HTTP methods that are specified in the Access-Control-Request-Method in a CORS request to your bucket must match the method or methods listed in the AllowedMethods element in your CORS configuration. A wildcard character ("*") in AllowedMethods would match all HTTP methods. For more information on how to update the AllowedOrigins element, see Configuring cross-origin resource sharing (CORS).

In a CORS configuration, you can specify the following methods in the AllowedMethods element:

  • GET

  • PUT

  • POST

  • DELETE

  • HEAD

The following example shows part of a CORS configuration that includes the GET method in the AllowedMethods element. Only requests including the GET method would succeed. 

"AllowedMethods":[
   "GET"
]

If an HTTP method (for example, PUT) was used in a CORS request or included in a pre-flight CORS request to your bucket but the method isn't present in your CORS configuration, the request would result in a 403 Forbidden error. To allow this CORS request or CORS pre-flight request, the PUT method must be added to your CORS configuration. 

"AllowedMethods":[
   "GET"
   "PUT"
]

Requested headers are not allowed

The headers listed in the Access-Control-Request-Headers header in a pre-flight request must match the headers in the AllowedHeaders element in your CORS configuration. For a list of common headers that can be used in requests to Amazon S3, see Common Request Headers. For more information on how to update the AllowedHeaders element, see Configuring cross-origin resource sharing (CORS).

The following example shows part of a CORS configuration that includes the Authorization header in the AllowedHeaders element. Only requests for the Authorization header would succeed. 

"AllowedHeaders":  [
    "Authorization"
]

If a header (for example Content-MD5 was included in a CORS request but the header isn't present in your CORS configuration, the request would result in a 403 Forbidden error. To allow this CORS request , the Content-MD5 header must be added to your CORS configuration. If you want to pass both Authorization and Content-MD5 headers in a CORS request to your bucket, confirm that both headers are included in the AllowedHeaders element in your CORS configuration. 

"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]

Headers not found in CORS response

The ExposeHeaders element in your CORS configuration identifies which response headers that you would like to make accessible to scripts and applications running in browsers, in response to a CORS request.

If your objects stored in your S3 bucket have user-defined metadata (for example, x-amz-meta-custom-header) along with the response data, this custom header could contain additional metadata or information that you want to access from your client-side JavaScript code. However, by default, browsers block access to custom headers for security reasons. To allow your client-side JavaScript to access custom headers, you need to include the header in your CORS configuration.

In the example below, the x-amz-meta-custom-header1 header is included in the ExposeHeaders element. The x-amz-meta-custom-header2 isn't included in the ExposeHeaders element and is missing from the CORS configuration. In the response, only the values included in the ExposeHeaders element would be returned. If the request included the x-amz-meta-custom-header2 header in the Access-Control-Expose-Headers header, the response would still return a 200 OK. However, only the permitted header, For example x-amz-meta-custom-header would be returned and show in the response. 

"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]

To ensure all headers appear in the response, add all permitted headers to the ExposeHeaders element in your CORS configuration as shown below. 

"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]

Considerations of CORS on S3 proxy integrations

If you are experiencing errors and have already checked the CORS configuration on your S3 bucket, and the cross-origin request is sent to proxies such as AWS CloudFront, try the following:

  • Configure the settings to allow the OPTIONS method for HTTP requests.

  • Configure the proxy to forward the following headers: Origin, Access-Control-Request-Headers, and Access-Control-Request-Method.

Some proxies provide pre-defined features for CORS requests. For example, in CloudFront, you can configure a policy that includes the headers that enable CORS requests when the origin is an S3 bucket. For more information, see Control origin requests with a policy and Use managed origin request policies in the CloudFront Developer Guide.