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
For the detailed guide supporting CloudFront development, I encourage you to check out the developer guide.
To add a response header policy using the AWS console, follow along below:
- Authenticate to your AWS environment
- Browse to
Distributions> (Your CloudFront Distribution)
- Select the
Behavior(May be path pattern: Default (*)) and select
- You’ll now see a new field labeled
Response headers policy - optional
- Click the drop-down to select a policy -
SecurityHeadersPolicywill cover a majority of the needed header attributes, including:
max-age: 31536000 (seconds)
Create Policyif customization is required
Save changeswhen 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.
Content-Security-PolicyContent 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.
Permissions-PolicyPermissions 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 :)
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!