Expand your security response headers using newly native Amazon CloudFront Response Headers!

It was recently (11/02/2021) announced that:

Today, Amazon CloudFront is launching support for response headers policies. You can now add cross-origin resource sharing (CORS), security, and custom headers to HTTP responses returned by your CloudFront distributions. You no longer need to configure your origins or use custom Lambda@Edge or CloudFront functions to insert these headers.

Why is this important? It further reduces our need to utilize CloudFront Functions (or even Lambda@Edge Functions) to handle CORS & appending security-related headers to responses. It also yields a pre-defined set of policies that can accommodate most security header related compliance.

Also - there are costs associated with running a CloudFront Function especially at the entry-point. If we can move it to the native functionality and still obtain the same result - it is the likely choice!

Table of Contents

• Implementation
  • Console
• How do we know it works?
  • What is it missing?
• Recap

Implementation

How do we implement a response header policy? It is currently supported using the AWS Console, AWS-CLI, AWS-SDK & Amazon CloudFormation.

For the detailed guide supporting CloudFront development, I encourage you to check out the developer guide.

Console

To add a response header policy using the AWS console, follow along below:

1. Authenticate to your AWS environment
2. Browse to CloudFront > Distributions > (Your CloudFront Distribution)
3. Select Behaviors
4. Select the Behavior (May be path pattern: Default (*)) and select Edit
5. You’ll now see a new field labeled Response headers policy - optional
6. Click the drop-down to select a policy - SecurityHeadersPolicy will cover a majority of the needed header attributes, including:
   • Strict-Transport-Security max-age: 31536000 (seconds)
   • X-Content-Type-Options Origin override
   • X-Frame-Options Origin: SAMEORIGIN
   • X-XSS-Protection enabled Block
   • Referrer-Policy strict-origin-when-cross-origin
   • Content-Security-Policy
7. Select SecurityHeaderPolicy or select Create Policy if customization is required
8. Select Save changes when complete

The CloudFront Distribution will then update accordingly.

How do we know it works?

I am a big fan of SecurityHeaders, an automated tool to provide an analysis of your security response headers for the inputted website.

After adding the SecurityHeadersPolicy - we can see below that the native response policy is performing as expected.

I’ve provided a link here to recheck the status.

What is it missing?

We see two security header values here missing from the default AWS provided SecurityHeadersPolicy policy. This is not a lack of the default (provided) policy missing these - it is seemingly at your discretion based on the security requirements.

1. Content-Security-Policy Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
2. Permissions-Policy Permissions Policy is a new header that allows a site to control which features and APIs can be used in the browser.

In this case, I am okay with leaving these two out. I do not wish to specify content-type at this time nor dictate the permissions that the content would ask for. Obviously this is all driven by use-case, and for a personal blog it’s not worth defining those values :)

Recap

It’s fantastic that AWS is listening to its user groups & defining a roadmap that yields these types of features to move from an appended ‘function’ to a native feature. I’m eager to see more of these types of roll-outs into the 2021 AWS Re:Invent season!