Cache all headers

[dylanratcliffe]

Instead of just the list, we will cache everything

[github-actions]

Expected Changes

cloudfront-response-headers-policy › 8ed09a88-177f-4f37-a844-66b7b54a7cda

--- current
+++ planned
@@ -3,11 +3,7 @@
     - access_control_allow_credentials: false
       access_control_allow_headers:
         - items:
-            - Accept
-            - Accept-Encoding
-            - Content-Encoding
-            - Content-Length
-            - Content-Type
+            - '*'
       access_control_allow_methods:
         - items:
             - GET

Blast Radius

Items	Edges
442	452

Open in Overmind

Risks

Potential Security Risk from Accepting All Headers [High]

By accepting all headers without restriction, potentially unsafe headers could be utilized by malicious users to exploit vulnerabilities within the application or infrastructure, leading to security breaches. This broad acceptance without validation increases the attack surface area. Considering the current strict whitelist, this change introduces a significant deviation from a secure default. Monitoring and controlling header input becomes critical and harder to manage, raising the level of vigilance required to maintain security posture.

Unintended Cache Behavior Impacting Origin Load [Medium]

Changing the aws_cloudfront_response_headers_policy to accept all headers (*) can lead to an unpredictable cache behavior. Currently, the policy is configured for a select set of headers, ensuring that only requests with these headers are cached. This change can result in increased cache misses as more unique combinations of headers will lead to requests being passed to the origin, thereby increasing the load and potentially affecting performance. The CloudFront distribution E15V1JM5GZXBKB, attached to S3 (s3-one-apt-catfish.s3.eu-west-2.amazonaws.com) and applications (appsync.terraform-aws-modules.modules.tf), could see varying impacts from increased origin load to potential cost increases due to more frequent origin fetches.

Impact on Compliance and Data Privacy [Medium]

The broad allowance of headers without specific whitelists may lead to unintentionally caching sensitive information or headers that should not be made cacheable according to compliance or data privacy requirements. This could potentially lead to data exposure or compliance violations, especially if personal data or sensitive information is unintentionally cached and served. The current setup with a specific set of headers likely aligns with existing data handling policies and changing this could necessitate a review of compliance with standards such as GDPR, HIPAA, etc.