Is it possible to set Content-Security-Policy headers in Amazon S3?

H

4

14

I'm trying to set a Content-Security-Policy header for an html file I'm serving via s3/cloudfront. I'm using the web-based AWS console. Whenever I try to add the header:

enter image description here

it doesn't seem to respect it. What can I do to make sure this header is served?

Hereabouts answered 6/11, 2013 at 23:48 Comment(1)

You can now use Lambda@Edge to alter the origin response before it gets cached in cloudfront aws.amazon.com/blogs/networking-and-content-delivery/… – Nicholasnichole 25/10, 2018 at 14:30

S

5

If you are testing through CloudFront, have you made sure you have invalidated the cached objects? Can you try to upload a completely new file and then try accessing it via CF and see if the header is still not there?

Update

Seems like custom metadata will not work as expected as per DOC. Any metadata other than the ones supported by S3 (the ones displayed in the dropdown) will have to be prefixed with x-amz-meta-

Sympathize answered 11/11, 2013 at 9:25 Comment(2)

No, this doesn't work. I uploaded a new file and set the header, but the header does not show up when accessed via cloudfront or s3. When I refresh the aws console, the header does not even appear under the metadata section, as if it were not saved. – Hereabouts 11/11, 2013 at 18:43

Seems like custom metadata will not work as expected as per docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html. Any metadata other than the ones supported by S3 (the ones displayed in the dropdown) will have to be prefixed with x-amz-meta- – Sympathize 11/11, 2013 at 19:6

T

10

I'm having the same problem (using S3/CloudFront) and it appears there is currently no way to set this up easily.

S3 has a whitelist of the headers permitted, and Content-Security-Policy is not on it. Whilst it is true you can use the prefixed x-amz-meta-Content-Security-Policy, this is unhelpful as there is no browser support for it.

There are two options I can see.

1) you can serve the html content from a webserver on an EC2 instance and set that up as another CloudFront origin. Not really a great solution.

2) include the CSP as a meta tag within your html document:

    <!doctype html>
    <html>
      <head>
        <meta http-equiv="Content-Security-Policy" content="default-src http://*.foobar.com 'self'">
...

This option is not as widely supported by browsers, but it appears to work with both Webkit and Firefox, so the current Chrome, Firefox, Safari (and IOS 7 Safari) seem to support it.

I chose 2 as it was the simpler/cheaper/faster solution and I hope AWS will add the CSP header in the future.

Triangular answered 19/11, 2014 at 6:34 Comment(1)

The second option is your best bet, but keep in mind that there are limitations to this. You can for example not use report-uri, frame-ancestors doens't work, and possibly some other things that I don't rember off the top of my head. – Boresome 17/5, 2016 at 11:38

F

6

S3/CloudFront takes any headers that the origin set and forward those to the client, but you can't set custom headers on you response directly.

You can use Lambda@Edge function that can inject security headers through CloudFront.

Here is how the process works: (reference aws blog)

Viewer navigates to website.
Before CloudFront serves content from the cache it will trigger any Lambda function associated with the Viewer Request trigger for that behavior.
CloudFront serves content from the cache if available, otherwise it goes to step 4.
Only after CloudFront cache ‘Miss’, Origin Request trigger is fired for that behavior.
S3 Origin returns content.
After content is returned from S3 but before being cached in CloudFront, Origin Response trigger is fired.
After content is cached in CloudFront, Viewer Response trigger is fired and is the final step before viewer receives content.
Viewer receives content.

Below is the blog from aws on how to do this step by step.

https://aws.amazon.com/blogs/networking-and-content-delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/

Fullbodied answered 23/9, 2019 at 17:2 Comment(3)

I've just had to do the same on my SPA that needs extra headers and this is the best way to do it. I have only one mention, use Origin Response trigger instead of Viewer Response to save money on lambda. Using the first one will cache the response with the headers (call the lambda@edge once for each region to initialise the cache), while the second one will use the lambda for each request. – Schriever 30/4, 2020 at 1:10

More documentation about how lambda@edge triggers work and which event is best to use here: aws.amazon.com/blogs/networking-and-content-delivery/… Includes cost optimisation details. – Schriever 30/4, 2020 at 6:59

Note that CloudFront in 2021 added native configuration support for CORS headers, so Lambda@Edge should not be needed for that anymore: aws.amazon.com/about-aws/whats-new/2021/11/… – Fancied 18/3, 2022 at 22:8

S

5

If you are testing through CloudFront, have you made sure you have invalidated the cached objects? Can you try to upload a completely new file and then try accessing it via CF and see if the header is still not there?

Update

Seems like custom metadata will not work as expected as per DOC. Any metadata other than the ones supported by S3 (the ones displayed in the dropdown) will have to be prefixed with x-amz-meta-

Sympathize answered 11/11, 2013 at 9:25 Comment(2)

No, this doesn't work. I uploaded a new file and set the header, but the header does not show up when accessed via cloudfront or s3. When I refresh the aws console, the header does not even appear under the metadata section, as if it were not saved. – Hereabouts 11/11, 2013 at 18:43

Seems like custom metadata will not work as expected as per docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html. Any metadata other than the ones supported by S3 (the ones displayed in the dropdown) will have to be prefixed with x-amz-meta- – Sympathize 11/11, 2013 at 19:6

D

0

not on S3 but you can do it on CloudFront...

go to your distribution -->Behaviours--> default (or if you are using a different one) -> Edit --> Under "Response headers policy" click "View Policy" ... then edit your response policy.. save it then our CF distribution will use this new response headers policy

Delphadelphi answered 6/8, 2024 at 13:8 Comment(0)

Recommended topics

Hot tags