# Add or remove HTTP headers in CloudFront responses with a policy You can configure CloudFront to modify the HTTP headers in the responses that it sends to viewers (web browsers and other clients). CloudFront can remove headers that it received from the origin, or add headers to the response, before sending the response to viewers. Making these changes doesn't require writing code or changing the origin. For example, you can remove headers such as `X-Powered-By` and `Vary` so that CloudFront doesn't include these headers in the responses that it sends to viewers. Or, you can add HTTP headers such as the following: + A `Cache-Control` header to control browser caching. + An `Access-Control-Allow-Origin` header to enable cross-origin resource sharing (CORS). You can also add other CORS headers. + A set of common security headers, such as `Strict-Transport-Security`, `Content-Security-Policy`, and `X-Frame-Options`. + A `Server-Timing` header to see information that's related to the performance and routing of both the request and response through CloudFront. To specify the headers that CloudFront adds or removes in HTTP responses, you use a *response headers policy*. You attach a response headers policy to one more *cache behaviors*, and CloudFront modifies the headers in the responses that it sends to requests that match the cache behavior. CloudFront modifies the headers in the responses that it serves from the cache and the ones that it forwards from the origin. If the origin response includes one or more of the headers that are added in a response headers policy, the policy can specify if CloudFront uses the header it received from the origin or overwrites that header with the one in the response headers policy. **Note** If you add headers that control browser caching to your response header policies, such as `Cache-Control`, CloudFront adds these headers to the *viewer response only*. These headers don't affect how CloudFront caches the requested object. CloudFront provides predefined response headers policies, known as *managed policies*, for common use cases. You can [use these managed policies](using-managed-response-headers-policies.md) or create your own policies. You can attach a single response headers policy to multiple cache behaviors in multiple distributions in your AWS account. For more information, see the following: **Topics** + [ # Understand response headers policies ](understanding-response-headers-policies.md) + [ # Create response headers policies ](creating-response-headers-policies.md) + [ # Use managed response headers policies ](using-managed-response-headers-policies.md) # Understand response headers policies You can use a response headers policy to specify the HTTP headers that Amazon CloudFront removes or adds in responses that it sends to viewers. For more information about response headers policies and reasons to use them, see [Add or remove HTTP headers in CloudFront responses with a policy](modifying-response-headers.md). The following topics explain the settings in a response headers policy. The settings are grouped into categories, which are represented in the following topics. **Topics** + [ ## Policy details (metadata) ](#understanding-response-headers-policies-details) + [ ## CORS headers ](#understanding-response-headers-policies-cors) + [ ## Security headers ](#understanding-response-headers-policies-security) + [ ## Custom headers ](#understanding-response-headers-policies-custom) + [ ## Remove headers ](#understanding-response-headers-policies-remove-headers) + [ ## Server-Timing header ](#server-timing-header) ## Policy details (metadata) The policy details settings contain metadata about a response headers policy. + **Name** – A name to identify the response headers policy. In the console, you use the name to attach the policy to a cache behavior. + **Description** (optional) – A comment to describe the response headers policy. This is optional, but it can help you identify the purpose of the policy. ## CORS headers The cross-origin resource sharing (CORS) settings allow you to add and configure CORS headers in a response headers policy. This list focuses on how to specify settings and valid values in a response headers policy. For more information about each of these headers and how they're used for real-world CORS requests and responses, see [cross-origin resource sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) in the MDN Web Docs and the [CORS protocol spec](https://fetch.spec.whatwg.org/#http-cors-protocol). **Access-Control-Allow-Credentials** This is a Boolean setting (`true` or `false`) that determines if CloudFront adds the `Access-Control-Allow-Credentials` header in responses to CORS requests. When this setting is set to `true`, CloudFront adds the `Access-Control-Allow-Credentials: true` header in responses to CORS requests. Otherwise, CloudFront doesn't add this header to responses. **Access-Control-Allow-Headers** Specifies the header names that CloudFront uses as values for the `Access-Control-Allow-Headers` header in responses to CORS preflight requests. Valid values for this setting include HTTP header names or the wildcard character (`*`), which indicates that all headers are allowed. The `Authorization` header can't use a wildcard and must be listed explicitly. **Examples of valid use of the wildcard character** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-response-headers-policies.html) **Access-Control-Allow-Methods** Specifies the HTTP methods that CloudFront uses as values for the `Access-Control-Allow-Methods` header in responses to CORS preflight requests. Valid values are `GET`, `DELETE`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, `PUT`, and `ALL`. `ALL` is a special value that includes all of the listed HTTP methods. **Access-Control-Allow-Origin** Specifies the values that CloudFront can use in the `Access-Control-Allow-Origin` response header. Valid values for this setting include a specific origin (such as `http://www.example.com`) or the wildcard character (`*`), which indicates that all origins are allowed. **Notes** + The wildcard character (`*`) is allowed as the leftmost subdomain (`*.example.org`). + The wildcard character (`*`) *isn't* allowed in the following positions: + Top-level domains (`example.*`) + To the right of subdomains (`test.*.example.org`) or within any subdomains (`*test.example.org`) + Inside of terms (`exa*mple.org)` For examples of ways to use the wildcard character, see the following table. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-response-headers-policies.html) **Access-Control-Expose-Headers** Specifies the header names that CloudFront uses as values for the `Access-Control-Expose-Headers` header in responses to CORS requests. Valid values for this setting include HTTP header names or the wildcard character (`*`). **Access-Control-Max-Age** A number of seconds, which CloudFront uses as the value for the `Access-Control-Max-Age` header in responses to CORS preflight requests. **Origin override** A Boolean setting that determines how CloudFront behaves when the response from the origin contains one of the CORS headers that's also in the policy. + When set to `true` and the origin response contains a CORS header that's also in the policy, CloudFront adds the CORS header in the policy to the response. CloudFront then sends that response to the viewer. CloudFront ignores the header that it received from the origin. + When set to `false` and the origin response contains a CORS header (regardless of whether the CORS header is in the policy), CloudFront includes the CORS header that it received from the origin to the response. CloudFront doesn't add any CORS headers in the policy to the response that is sent to the viewer. ## Security headers You can use the security headers settings to add and configure several security-related HTTP response headers in a response headers policy. This list describes how you can specify settings and valid values in a response headers policy. For more information about each of these headers and how they're used in real-world HTTP responses, see the links to the MDN Web Docs. **Content-Security-Policy** Specifies the content security policy directives that CloudFront uses as values for the `Content-Security-Policy` response header. For more information about this header and valid policy directives, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) in the MDN Web Docs. The `Content-Security-Policy` header value is limited to 1783 characters. **Referrer-Policy** Specifies the referrer policy directive that CloudFront uses as the value for the `Referrer-Policy` response header. Valid values for this setting are `no-referrer`, `no-referrer-when-downgrade`, `origin`, `origin-when-cross-origin`, `same-origin`, `strict-origin`, `strict-origin-when-cross-origin`, and `unsafe-url`. For more information about this header and these directives, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) in the MDN Web Docs. **Strict-Transport-Security** Specifies the directives and settings that CloudFront uses as the value for the `Strict-Transport-Security` response header. For this setting, you separately specify: + A number of seconds, which CloudFront uses as the value for the `max-age` directive of this header + A Boolean setting (`true` or `false`) for `preload`, which determines whether CloudFront includes the `preload` directive in the value of this header + A Boolean setting (`true` or `false`) for `includeSubDomains`, which determines whether CloudFront includes the `includeSubDomains` directive in the value of this header For more information about this header and these directives, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) in the MDN Web Docs. **X-Content-Type-Options** This is a Boolean setting (`true` or `false`) that determines if CloudFront adds the `X-Content-Type-Options` header to responses. When this setting is `true`, CloudFront adds the `X-Content-Type-Options: nosniff` header to responses. Otherwise CloudFront doesn't add this header. For more information about this header, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) in the MDN Web Docs. **X-Frame-Options** Specifies the directive that CloudFront uses as the value for the `X-Frame-Options` response header. Valid values for this setting are `DENY` or `SAMEORIGIN`. For more information about this header and these directives, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options) in the MDN Web Docs. **X-XSS-Protection** Specifies the directives and settings that CloudFront uses as the value for the `X-XSS-Protection` response header. For this setting, you separately specify: + An `X-XSS-Protection` setting of `0` (disables XSS filtering) or `1` (enables XSS filtering) + A Boolean setting (`true` or `false`) for `block`, which determines whether CloudFront includes the `mode=block` directive in the value for this header + A reporting URI, which determines whether CloudFront includes the `report=reporting URI` directive in the value for this header You can specify `true` for `block`, or you can specify a reporting URI, but you can't specify both together. For more information about this header and these directives, see [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection) in the MDN Web Docs. **Origin override** Each of these security headers settings contains a Boolean setting (`true` or `false`) that determines how CloudFront behaves when the response from the origin contains that header. When this setting is set to `true` and the origin response contains the header, CloudFront adds the header in the policy to the response that it sends to the viewer. It ignores the header that it received from the origin. When this setting is set to `false` and the origin response contains the header, CloudFront includes the header that it received from the origin in the response that it sends to the viewer. When the origin response doesn't contain the header, CloudFront adds the header in the policy to the response that it sends to the viewer. CloudFront does this when this setting is set to `true` or `false`. ## Custom headers You can use custom headers settings to add and configure custom HTTP headers in a response headers policy. CloudFront adds these headers to every response that it returns to viewers. For each custom header, you also specify the value for the header, though specifying a value is optional. This is because CloudFront can add a response header with no value. Each custom header also has its own **Origin override** setting: + When this setting is set to `true` and the origin response contains the custom header that's in the policy, CloudFront adds the custom header in the policy to the response that it sends to the viewer. It ignores the header that it received from the origin. + When this setting is `false` and the origin response contains the custom header that's in the policy, CloudFront includes the custom header that it received from the origin in the response that it sends to the viewer. + When the origin response doesn't contain the custom header that's in the policy, CloudFront adds the custom header in the policy to the response that it sends to the viewer. CloudFront does this when this setting is set to `true` or `false`. ## Remove headers You can specify headers that you want CloudFront to remove from the responses it receives from the origin so the headers are not included in the responses that CloudFront sends to viewers. CloudFront removes the headers from every response it sends to viewers, whether the objects is served from CloudFront's cache or from the origin. For example, you can remove headers that are of no use to browsers, such as `X-Powered-By` or `Vary`, so that CloudFront removes these headers from the responses that it sends to viewers. When you specify headers to remove using a response headers policy, CloudFront removes the headers first and then adds any headers that are specified in other sections of the response headers policy (CORS headers, security headers, custom headers, etc.). If you specify a header to remove but also add the same header in another section of the policy, CloudFront includes the header in the responses that it sends to viewers. **Note** You can use a response headers policy to remove the `Server` and `Date` headers that CloudFront received from the origin, so that these headers (as received from the origin) are not included in the responses that CloudFront sends to viewers. However, if you do that, CloudFront adds its own version of these headers to responses that it sends to viewers. For the `Server` header that CloudFront adds, the header's value is `CloudFront`. ### Headers that you can't remove You cannot remove the following headers using a response headers policy. If you specify these headers in the **Remove headers** section of a response headers policy (`ResponseHeadersPolicyRemoveHeadersConfig` in the API), you receive an error. + `Connection` + `Content-Encoding` + `Content-Length` + `Expect` + `Host` + `Keep-Alive` + `Proxy-Authenticate` + `Proxy-Authorization` + `Proxy-Connection` + `Trailer` + `Transfer-Encoding` + `Upgrade` + `Via` + `Warning` + `X-Accel-Buffering` + `X-Accel-Charset` + `X-Accel-Limit-Rate` + `X-Accel-Redirect` + `X-Amz-Cf-.*` + `X-Amzn-Auth` + `X-Amzn-Cf-Billing` + `X-Amzn-Cf-Id` + `X-Amzn-Cf-Xff` + `X-Amzn-ErrorType` + `X-Amzn-Fle-Profile` + `X-Amzn-Header-Count` + `X-Amzn-Header-Order` + `X-Amzn-Lambda-Integration-Tag` + `X-Amzn-RequestId` + `X-Cache` + `X-Edge-.*` + `X-Forwarded-Proto` + `X-Real-Ip` ## Server-Timing header Use the `Server-Timing` header setting to enable the `Server-Timing` header in HTTP responses sent from CloudFront. You can use this header to view metrics that can help you gain insights about the behavior and performance of CloudFront and your origin. For example, you can see which cache layer served a cache hit. Or, you can see the first byte latency from the origin if there's a cache miss. The metrics in the `Server-Timing` header can help you troubleshoot issues or test the efficiency of your CloudFront or origin configuration. For more information about using the `Server-Timing` header with CloudFront, see the following topics. To enable the `Server-Timing` header, [create (or edit) a response headers policy](creating-response-headers-policies.md). **Topics** + [ ### Sampling rate and Pragma request header ](#server-timing-header-sampling-rate) + [ ### Server-Timing header from the origin ](#server-timing-header-origin) + [ ### Server-Timing header metrics ](#server-timing-header-metrics) + [ ### Server-Timing header examples ](#server-timing-header-examples) ### Sampling rate and Pragma request header When you enable the `Server-Timing` header in a response headers policy, you also specify the *sampling rate*. The sampling rate is a number 0–100 (inclusive) that specifies the percentage of responses that you want CloudFront to add the `Server-Timing` header to. When you set the sampling rate to 100, CloudFront adds the `Server-Timing` header to the HTTP response for every request that matches the cache behavior that the response headers policy is attached to. When you set it to 50, CloudFront adds the header to 50% of the responses for requests that match the cache behavior. You can set the sampling rate to any number 0–100 with up to four decimal places. When the sampling rate is set to a number lower than 100, you can't control which responses CloudFront adds the `Server-Timing` header to, only the percentage. However, you can add the `Pragma` header with a value set to `server-timing` in an HTTP request to receive the `Server-Timing` header in the response to that request. This works no matter what the sampling rate is set to. Even when the sampling rate is set to zero (0), CloudFront adds the `Server-Timing` header to the response if the request contains the `Pragma: server-timing` header. ### Server-Timing header from the origin When there is a cache miss and CloudFront forwards the request to the origin, the origin might include a `Server-Timing` header in its response to CloudFront. In this case, CloudFront adds its [metrics](#server-timing-header-metrics) to the `Server-Timing` header that it received from the origin. The response that CloudFront sends to the viewer contains a single `Server-Timing` header that includes the value that came from the origin and the metrics that CloudFront added. The header value from the origin might be at the end, or in between two sets of metrics that CloudFront adds to the header. When there is a cache hit, the response that CloudFront sends to the viewer contains a single `Server-Timing` header that includes only the CloudFront metrics in the header value (the value from the origin is not included). ### Server-Timing header metrics When CloudFront adds the `Server-Timing` header to an HTTP response, the value of the header contains one or more metrics that can help you gain insights about the behavior and performance of CloudFront and your origin. The following list contains all the metrics and their potential values. A `Server-Timing` header contains only some of these metrics, depending on the nature of the request and response through CloudFront. Some of these metrics are included in the `Server-Timing` header with a name only (no value). Others are a name and a value. When a metric has a value, the name and value are separated by a semicolon (`;`). When the header contains more than one metric, the metrics are separated by a comma (`,`). **cdn-cache-hit** CloudFront provided a response from the cache without making a request to the origin. **cdn-cache-refresh** CloudFront provided a response from the cache after sending a request to the origin to verify that the cached object is still valid. In this case, CloudFront didn't retrieve the full object from the origin. **cdn-cache-miss** CloudFront didn't provide the response from the cache. In this case, CloudFront requested the full object from the origin before returning the response. **cdn-pop** Contains a value that describes which CloudFront point of presence (POP) handled the request. **cdn-rid** Contains a value with the CloudFront unique identifier for the request. You can use this request identifier (RID) when troubleshooting issues with Support **cdn-hit-layer** This metric is present when CloudFront provides a response from the cache without making a request to the origin. It contains one of the following values: + **EDGE** – CloudFront provided the cached response from a POP location. + **REC** – CloudFront provided the cached response from a [regional edge cache](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) (REC) location. + **Origin Shield** – CloudFront provided the cached response from the REC that's acting as [Origin Shield](origin-shield.md). **cdn-upstream-layer** When CloudFront requests the full object from the origin, this metric is present and contains one of the following values: + **EDGE** – A POP location sent the request directly to the origin. + **REC** – A REC location sent the request directly to the origin. + **Origin Shield** – The REC that's acting as [Origin Shield](origin-shield.md) sent the request directly to the origin. **cdn-upstream-dns** Contains a value with the number of milliseconds that were spent retrieving the DNS record for the origin. A value of zero (0) indicates that CloudFront used a cached DNS result or reused an existing connection. **cdn-upstream-connect** Contains a value with the number of milliseconds between when the origin DNS request completed and a TCP (and TLS, if applicable) connection to the origin completed. A value of zero (0) indicates that CloudFront reused an existing connection. **cdn-upstream-fbl** Contains a value with the number of milliseconds between when the origin HTTP request is completed and when the first byte is received in the response from the origin (first byte latency). **cdn-downstream-fbl** Contains a value with the number of milliseconds between when the edge location finished receiving the request and when it sent the first byte of the response to the viewer. ### Server-Timing header examples The following are examples of a `Server-Timing` header that a viewer might receive from CloudFront when the `Server-Timing` header setting is enabled. **Example – cache miss** The following example shows a `Server-Timing` header that a viewer might receive when the requested object is not in the CloudFront cache. ``` Server-Timing: cdn-upstream-layer;desc="EDGE",cdn-upstream-dns;dur=0,cdn-upstream-connect;dur=114,cdn-upstream-fbl;dur=177,cdn-cache-miss,cdn-pop;desc="PHX50-C2",cdn-rid;desc="yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg==",cdn-downstream-fbl;dur=436 ``` This `Server-Timing` header indicates the following: + The origin request was sent from a CloudFront point of presence (POP) location (`cdn-upstream-layer;desc="EDGE"`). + CloudFront used a cached DNS result for the origin (`cdn-upstream-dns;dur=0`). + It took 114 milliseconds for CloudFront to complete the TCP (and TLS, if applicable) connection to the origin (`cdn-upstream-connect;dur=114`). + It took 177 milliseconds for CloudFront to receive the first byte of the response from the origin, after completing the request (`cdn-upstream-fbl;dur=177`). + The requested object wasn't in CloudFront's cache (`cdn-cache-miss`). + The request was received at the edge location identified by the code `PHX50-C2` (`cdn-pop;desc="PHX50-C2"`). + The CloudFront unique ID for this request was `yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg==` (`cdn-rid;desc="yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg=="`). + It took 436 milliseconds for CloudFront to send the first byte of the response to the viewer, after receiving the viewer request (`cdn-downstream-fbl;dur=436`). **Example – cache hit** The following example shows a `Server-Timing` header that a viewer might receive when the requested object is in CloudFront's cache. ``` Server-Timing: cdn-cache-hit,cdn-pop;desc="SEA19-C1",cdn-rid;desc="nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g==",cdn-hit-layer;desc="REC",cdn-downstream-fbl;dur=137 ``` This `Server-Timing` header indicates the following: + The requested object was in the cache (`cdn-cache-hit`). + The request was received at the edge location identified by the code `SEA19-C1` (`cdn-pop;desc="SEA19-C1"`). + The CloudFront unique ID for this request was `nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g==` (`cdn-rid;desc="nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g=="`). + The requested object was cached in a regional edge cache (REC) location (`cdn-hit-layer;desc="REC"`). + It took 137 milliseconds for CloudFront to send the first byte of the response to the viewer, after receiving the viewer request (`cdn-downstream-fbl;dur=137`). # Create response headers policies You can use a response headers policy to specify the HTTP headers that Amazon CloudFront adds or removes in HTTP responses. For more information about response headers policies and reasons to use them, see [Add or remove HTTP headers in CloudFront responses with a policy](modifying-response-headers.md). You can create a response headers policy in the CloudFront console. Or you can create one by using AWS CloudFormation, the AWS Command Line Interface (AWS CLI), or the CloudFront API. After you create a response headers policy, you attach it to one or more cache behaviors in a CloudFront distribution. Before you create a custom response headers policy, check if one of the [managed response headers policies](using-managed-response-headers-policies.md) fits your use case. If one does, you can attach it to your cache behavior. That way, you don't need to create or manage your own response headers policy. ------ #### [ Console ] **To create a response headers policy (console)** 1. Sign in to the AWS Management Console, then go to the **Response headers** tab on the **Policies** page in the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders). 1. Choose **Create response headers policy**. 1. In the **Create response headers policy** form, do the following: 1. In the **Details** panel, enter a **Name** for the response headers policy and (optionally) a **Description** that explains what the policy is for. 1. In the **Cross-origin resource sharing (CORS)** panel, choose the **Configure CORS** toggle and configure any CORS headers that you want to add to the policy. If you want the configured headers to override the headers that CloudFront receives from the origin, select the **Origin override** check box. For more information about the CORS headers settings, see [CORS headers](understanding-response-headers-policies.md#understanding-response-headers-policies-cors). 1. In the **Security headers** panel, choose the toggle and configure each of the security headers that you want to add to the policy. For more information about the security headers settings, see [Security headers](understanding-response-headers-policies.md#understanding-response-headers-policies-security). 1. In the **Custom headers** panel, add any custom headers that you want to include in the policy. For more information about the custom headers settings, see [Custom headers](understanding-response-headers-policies.md#understanding-response-headers-policies-custom). 1. In the **Remove headers** panel, add the names of any headers that you want CloudFront to remove from the origin's response and not include in the response that CloudFront sends to viewers. For more information about the remove headers settings, see [Remove headers](understanding-response-headers-policies.md#understanding-response-headers-policies-remove-headers). 1. In the **Server-Timing header** panel, choose the **Enable** toggle and enter a sampling rate (a number between 0 and 100, inclusive). For more information about the `Server-Timing` header, see [Server-Timing header](understanding-response-headers-policies.md#server-timing-header). 1. Choose **Create** to create the policy. After you create a response headers policy, you can attach it to a cache behavior in a CloudFront distribution. **To attach a response headers policy to an existing distribution (console)** 1. Open the **Distributions** page in the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home#/distributions](https://console.aws.amazon.com/cloudfront/v4/home#/distributions). 1. Choose the distribution to update, then choose the **Behaviors** tab. 1. Select the cache behavior to update, then choose **Edit**. Or, to create a new cache behavior, choose **Create behavior**. 1. For **Response headers policy**, choose the policy to add to the cache behavior. 1. Choose **Save changes** to update the cache behavior. If you're creating a new cache behavior, choose **Create behavior**. **To attach a response headers policy to a new distribution (console)** 1. Open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Choose **Create distribution**. 1. For **Response headers policy**, choose the policy to add to the cache behavior. 1. Choose the other settings for your distribution. For more information, see [All distribution settings reference](distribution-web-values-specify.md). 1. Choose **Create distribution** to create the distribution. ------ #### [ CloudFormation ] To create a response headers policy with CloudFormation, use the `AWS::CloudFront::ResponseHeadersPolicy` resource type. The following example shows the CloudFormation template syntax, in YAML format, for creating a response headers policy. ``` Type: AWS::CloudFront::ResponseHeadersPolicy Properties: ResponseHeadersPolicyConfig: Name: EXAMPLE-Response-Headers-Policy Comment: Example response headers policy for the documentation CorsConfig: AccessControlAllowCredentials: false AccessControlAllowHeaders: Items: - '*' AccessControlAllowMethods: Items: - GET - OPTIONS AccessControlAllowOrigins: Items: - https://example.com - https://docs.example.com AccessControlExposeHeaders: Items: - '*' AccessControlMaxAgeSec: 600 OriginOverride: false CustomHeadersConfig: Items: - Header: Example-Custom-Header-1 Value: value-1 Override: true - Header: Example-Custom-Header-2 Value: value-2 Override: true SecurityHeadersConfig: ContentSecurityPolicy: ContentSecurityPolicy: default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'; frame-ancestors 'none' Override: false ContentTypeOptions: # You don't need to specify a value for 'X-Content-Type-Options'. # Simply including it in the template sets its value to 'nosniff'. Override: false FrameOptions: FrameOption: DENY Override: false ReferrerPolicy: ReferrerPolicy: same-origin Override: false StrictTransportSecurity: AccessControlMaxAgeSec: 63072000 IncludeSubdomains: true Preload: true Override: false XSSProtection: ModeBlock: true # You can set ModeBlock to 'true' OR set a value for ReportUri, but not both Protection: true Override: false ServerTimingHeadersConfig: Enabled: true SamplingRate: 50 RemoveHeadersConfig: Items: - Header: Vary - Header: X-Powered-By ``` For more information, see [AWS::CloudFront::ResponseHeadersPolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-responseheaderspolicy.html) in the *AWS CloudFormation User Guide*. ------ #### [ CLI ] To create a response headers policy with the AWS Command Line Interface (AWS CLI), use the **aws cloudfront create-response-headers-policy** command. You can use an input file to provide the input parameters for the command, rather than specifying each individual parameter as command line input. **To create a response headers policy (CLI with input file)** 1. Use the following command to create a file that's named `response-headers-policy.yaml`. This file contains all of the input parameters for the **create-response-headers-policy** command. ``` aws cloudfront create-response-headers-policy --generate-cli-skeleton yaml-input > response-headers-policy.yaml ``` 1. Open the `response-headers-policy.yaml` file that you just created. Edit the file to specify a policy name and the desired response headers policy configuration, then save the file. For more information about the response headers policy settings, see [Understand response headers policies](understanding-response-headers-policies.md). 1. Use the following command to create the response headers policy. The policy that you create uses the input parameters from the `response-headers-policy.yaml` file. ``` aws cloudfront create-response-headers-policy --cli-input-yaml file://response-headers-policy.yaml ``` Make note of the `Id` value in the command output. This is the response headers policy ID. You need it to attach the policy to the cache behavior of a CloudFront distribution. **To attach a response headers policy to an existing distribution (CLI with input file)** 1. Use the following command to save the distribution configuration for the CloudFront distribution that you want to update. Replace *distribution\$1ID* with the distribution ID. ``` aws cloudfront get-distribution-config --id distribution_ID --output yaml > dist-config.yaml ``` 1. Open the file that's named `dist-config.yaml` that you just created. Edit the file, making the following changes to the cache behavior to make it use the response headers policy. + In the cache behavior, add a field that's named `ResponseHeadersPolicyId`. For the field's value, use the response headers policy ID that you noted after creating the policy. + Rename the `ETag` field to `IfMatch`, but don't change the field's value. Save the file when finished. 1. Use the following command to update the distribution to use the response headers policy. Replace *distribution\$1ID* with the distribution ID. ``` aws cloudfront update-distribution --id distribution_ID --cli-input-yaml file://dist-config.yaml ``` **To attach a response headers policy to a new distribution (CLI with input file)** 1. Use the following command to create a file that's named `distribution.yaml`. This file contains all of the input parameters for the **create-distribution** command. ``` aws cloudfront create-distribution --generate-cli-skeleton yaml-input > distribution.yaml ``` 1. Open the `distribution.yaml` file that you just created. In the default cache behavior, in the `ResponseHeadersPolicyId` field, enter the response headers policy ID that you noted after creating the policy. Continue editing the file to specify the distribution settings that you want, then save the file when finished. For more information about the distribution settings, see [All distribution settings reference](distribution-web-values-specify.md). 1. Use the following command to create the distribution using input parameters from the `distribution.yaml` file. ``` aws cloudfront create-distribution --cli-input-yaml file://distribution.yaml ``` ------ #### [ API ] To create a response headers policy with the CloudFront API, use [CreateResponseHeadersPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateResponseHeadersPolicy.html). For more information about the fields that you specify in this API call, see [Understand response headers policies](understanding-response-headers-policies.md) and the API reference documentation for your AWS SDK or other API client. After you create a response headers policy, you can attach it to a cache behavior, using one of the following API calls: + To attach it to a cache behavior in an existing distribution, use [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html). + To attach it to a cache behavior in a new distribution, use [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html). For both of these API calls, provide the response headers policy ID in the `ResponseHeadersPolicyId` field, inside a cache behavior. For more information about the other fields that you specify in these API calls, see [All distribution settings reference](distribution-web-values-specify.md) and the API reference documentation for your AWS SDK or other API client. ------ # Use managed response headers policies With a CloudFront response headers policy, you can specify the HTTP headers that Amazon CloudFront removes or adds in responses that it sends to viewers. For more information about response headers policies and reasons to use them, see [Add or remove HTTP headers in CloudFront responses with a policy](modifying-response-headers.md). CloudFront provides managed response headers policies that you can attach to cache behaviors in your CloudFront distributions. With a managed response headers policy, you don't need to write or maintain your own policy. The managed policies contain sets of HTTP response headers for common use cases. To use a managed response headers policy, you attach it to a cache behavior in your distribution. The process is the same as when you create a custom response headers policy. However, instead of creating a new policy, you attach one of the managed policies. You attach the policy either by name (with the console) or by ID (with CloudFormation, the AWS CLI, or the AWS SDKs). The names and IDs are listed in the following section. For more information, see [Create response headers policies](creating-response-headers-policies.md). The following topics describe the managed response headers policies that you can use. **Topics** + [ ## CORS-and-SecurityHeadersPolicy ](#managed-response-headers-policies-cors-security) + [ ## CORS-With-Preflight ](#managed-response-headers-policies-cors-preflight) + [ ## CORS-with-preflight-and-SecurityHeadersPolicy ](#managed-response-headers-policies-cors-preflight-security) + [ ## SecurityHeadersPolicy ](#managed-response-headers-policies-security) + [ ## SimpleCORS ](#managed-response-headers-policies-cors) ## CORS-and-SecurityHeadersPolicy [View this policy in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders/e61eb60c-9c35-4d20-a928-2b84e02af89c) Use this managed policy to allow simple CORS requests from any origin. This policy also adds a set of security headers to all responses that CloudFront sends to viewers. This policy combines the [SimpleCORS](#managed-response-headers-policies-cors) and [SecurityHeadersPolicy](#managed-response-headers-policies-security) policies into one. When using CloudFormation, the AWS CLI, or the CloudFront API, the ID for this policy is: `e61eb60c-9c35-4d20-a928-2b84e02af89c` **Policy settings** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-response-headers-policies.html) ## CORS-With-Preflight [View this policy in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders/5cc3b908-e619-4b99-88e5-2cf7f45965bd) Use this managed policy to allow CORS requests from any origin, including preflight requests. For preflight requests (using the HTTP `OPTIONS` method), CloudFront adds all three of the following headers to the response. For simple CORS requests, CloudFront adds only the `Access-Control-Allow-Origin` header. If the response that CloudFront receives from the origin includes any of these headers, CloudFront uses the received header (and its value) in its response to the viewer. CloudFront doesn't use the header in this policy. When using CloudFormation, the AWS CLI, or the CloudFront API, the ID for this policy is: `5cc3b908-e619-4b99-88e5-2cf7f45965bd` **Policy settings** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-response-headers-policies.html) ## CORS-with-preflight-and-SecurityHeadersPolicy [View this policy in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders/eaab4381-ed33-4a86-88ca-d9558dc6cd63) Use this managed policy to allow CORS requests from any origin. This includes preflight requests. This policy also adds a set of security headers to all responses that CloudFront sends to viewers. This policy combines the [CORS-With-Preflight](#managed-response-headers-policies-cors-preflight) and [SecurityHeadersPolicy](#managed-response-headers-policies-security) policies into one. When using CloudFormation, the AWS CLI, or the CloudFront API, the ID for this policy is: `eaab4381-ed33-4a86-88ca-d9558dc6cd63` **Policy settings** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-response-headers-policies.html) ## SecurityHeadersPolicy [View this policy in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders/67f7725c-6f97-4210-82d7-5512b31e9d03) Use this managed policy to add a set of security headers to all responses that CloudFront sends to viewers. For more information about these security headers, see [Mozilla's web security guidelines](https://infosec.mozilla.org/guidelines/web_security). With this response headers policy, CloudFront adds `X-Content-Type-Options: nosniff` to all responses. This is the case when the response that CloudFront received from the origin included this header and when it didn't. For all other headers in this policy, if the response that CloudFront receives from the origin includes the header, CloudFront uses the received header (and its value) in its response to the viewer. It doesn't use the header in this policy. When using CloudFormation, the AWS CLI, or the CloudFront API, the ID for this policy is: `67f7725c-6f97-4210-82d7-5512b31e9d03` **Policy settings** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-response-headers-policies.html) ## SimpleCORS [View this policy in the CloudFront console](https://console.aws.amazon.com/cloudfront/v4/home#/policies/responseHeaders/60669652-455b-4ae9-85a4-c4c02393f86c) Use this managed policy to allow [simple CORS requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) from any origin. With this policy, CloudFront adds the header `Access-Control-Allow-Origin: *` to all responses for simple CORS requests. If the response that CloudFront receives from the origin includes the `Access-Control-Allow-Origin` header, CloudFront uses that header (and its value) in its response to the viewer. CloudFront doesn't use the header in this policy. When using CloudFormation, the AWS CLI, or the CloudFront API, the ID for this policy is: `60669652-455b-4ae9-85a4-c4c02393f86c` **Policy settings** | | Header name | Header value | Override origin? | | --- | --- | --- | --- | | CORS headers: | Access-Control-Allow-Origin | \$1 | No |