Skip to main content

🛡️ AWS CloudFront Web Distribution Default Root Object is not configured🟢

  • Contextual name: 🛡️ Web Distribution Default Root Object is not configured🟢
  • ID: /ce/ca/aws/cloudfront/distribution-default-root-object
  • Tags:
  • Policy Type: BEST_PRACTICE
  • Policy Categories: SECURITY

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-4f944d131

Description​

Open File

Description​

Ensure that AWS CloudFront Web Distributions are configured with a Default Root Object.

A Default Root Object (for example index.html) is the object that CloudFront returns when a client requests the distribution’s root URL (e.g., https://example.com/) rather than specifying a particular object in the distribution (e.g., https://www.example.com/product-description.html).

A Default Root Object is most appropriate when your distribution serves a website or static content entry point and you expect clients to access / directly. Common scenarios include:

  • Static websites or landing pages, ensuring that GET / returns an index.html or equivalent landing page.
  • Documentation hubs or single‑page apps.

Conversely, you typically omit a Default Root Object when:

  • Your distribution fronts APIs or microservices and clients always request specific paths.
  • Your origin itself (e.g., a dynamic web server behind an ALB) handles root requests.
  • You rely on routing logic via Lambda@Edge, CloudFront Functions, or S3 website‑endpoint error‑page configurations.

... see more

Remediation​

Open File

Remediation​

From Command Line​

You can update the Default Root Object by using the --default-root-object flag:

aws cloudfront update-distribution \
    --id {{distribution-id}} \
    --default-root-object {{index.html}}

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [CloudFront.1] CloudFront distributions should have a default root object configured11no data
💼 Cloudaware Framework → 💼 Public and Anonymous Access106no data
💼 FedRAMP High Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)3772no data
💼 FedRAMP High Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)1152no data
💼 FedRAMP Low Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)72no data
💼 FedRAMP Moderate Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)72no data
💼 FedRAMP Moderate Security Controls → 💼 AC-4(21) Physical or Logical Separation of Information Flows (M)(H)52no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties120no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected156no data
💼 NIST CSF v2.0 → 💼 PR.IR-01: Networks and environments are protected from unauthorized logical access and usage103no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3 Access Enforcement15544no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-4(21) Information Flow Enforcement _ Physical or Logical Separation of Information Flows3752no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-7(11) Boundary Protection _ Restrict Incoming Communications Traffic28no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-7(16) Boundary Protection _ Prevent Discovery of System Components29no data
💼 PCI DSS v3.2.1 → 💼 2.2.4 Configure system security parameters to prevent misuse.16no data
💼 PCI DSS v4.0.1 → 💼 2.2.6 System security parameters are configured to prevent misuse.16no data
💼 PCI DSS v4.0 → 💼 2.2.6 System security parameters are configured to prevent misuse.1216no data
💼 UK Cyber Essentials → 💼 2.1.5 Ensure users are authenticated before allowing them access to organizational data or services44no data