CloudFront distributions without a default root object defined

0

Hi,

We have CloudFront distributions that have been flagged by Security Hub for not having a default root object defined: https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1

For example we have two distributions with no default root object defined and the below behaviors:

Path pattern           Origin type
/media/*               S3 Bucket
Default (*)            ELB

and

Path pattern           Origin type
/assets/*              S3 Bucket
Default (*)            API Gateway
  1. Am I correct in stating that, in the examples above, since the Default (*) behaviour does not point to an S3 Origin, the Security Hub finding can be 'suppressed' since not having a default root object in those two cases do not pose a security risk ?

  2. If I am wrong and always having a root object is best practice, how would you remediate the distributions above given as example ? Because if I define a default root object for the second distribution above, all my API requests sent to my root URL will go to https://mydomain.com/myrootobject.html instead of going to https://mydomain.com/

And finally we have an origin without a default root object that could be problematic:

for example:

Path pattern           Origin type
Default (*)            S3 Origin

Our origin S3 bucket is Private, with ACL disabled and with Origin Access Control (OAC - Always sign requests) enabled on CloudFront and with the below S3 Policy:

        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::mybucket/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::000000000:distribution/XXXXXXXXXXX"
                }
            }

The below documentation states that "Under any of the following conditions, the contents of your origin are visible to anyone who uses CloudFront to access your distribution:" [if] "An end user accesses your origin using your origin root URL." https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectNotSet

However, when using our root URL (either via our domain name or directly via the CloudFront domain name), CloudFront returns a 403 "Access denied" response, hence I cannot see the content of the S3 Bucket.

  1. Is the statement of "Under any of the following conditions" from the AWS documentation not accurate then or am I missing something ? Why can't I access the contents of the S3 bucket when using the root URL ?
  2. Is it still highly recommended to define a default root object on the CloudFront distribution given the configuration of our S3 bucket ? Because if we define a root object for this distribution, we would have to define and maintain all the path patterns that we require, which we probably wouldn't want to do if there is no security risk in our case.

Thanks in advance for the help on any of the 4 questions above :)

1 Answer
0

Hello.

  1. Am I correct in stating that, in the examples above, since the Default (*) behaviour does not point to an S3 Origin, the Security Hub finding can be 'suppressed' since not having a default root object in those two cases do not pose a security risk ?

Configure CloudFront's default root object using the steps in the following document.
I don't think this has anything to do with whether the behavior points to the S3 origin.
I believe that if you configure the settings in the document below, Security Hub detection will be successful.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html

  1. If I am wrong and always having a root object is best practice, how would you remediate the distributions above given as example ? Because if I define a default root object for the second distribution above, all my API requests sent to my root URL will go to https://mydomain.com/myrootobject.html instead of going to https://mydomain.com/

In the case of ELB, I think you should set the content of the document root such as EC2 in the target group.
In the case of API Gateway, I think it's a good idea to set the route you want to respond to when accessed with "/".

  1. Is the statement of "Under any of the following conditions" from the AWS documentation not accurate then or am I missing something ? Why can't I access the contents of the S3 bucket when using the root URL ?

In my environment, I can access index.html set as the default root object by specifying the URL.
Also, is CloudFront's default root object set correctly?

https://yyyyyyy.cloudfront.net/index.html
  1. Is it still highly recommended to define a default root object on the CloudFront distribution given the configuration of our S3 bucket ? Because if we define a root object for this distribution, we would have to define and maintain all the path patterns that we require, which we probably wouldn't want to do if there is no security risk in our case.

I think setting a default root object helps prevent unexpected content from being displayed.
For example, if the origin is S3, I think that a mistake in the bucket policy settings could cause all objects to be displayed.
I think the settings are effective to prevent such situations.
Basically, I don't think there is any problem even if you don't control it with CloudFront as long as it can be controlled on the origin side.

profile picture
EXPERT
answered 7 months ago
profile pictureAWS
EXPERT
reviewed 7 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions