Implementation Of Custom-header to Origin requests

Security Jul 12, 2021

Every public endpoint which provides static or dynamic content is eligible to improve their performance, availability, and security by using Amazon CloudFront as your content delivery network (CDN) if applicable. CloudFront is a web service that speeds up the distribution of your web content through edge locations. CloudFront ensures that end-user requests are served by the nearest edge location which results in, viewer requests travel a short distance with the least latency, improves performance for the viewers. When you deliver web content through a CloudFront, a best practice is to prevent viewer requests from bypassing the CDN(CloudFront) and accessing your origin content directly.

In this blog post, we’ll see how to use CloudFront custom headers to restrict viewer requests from accessing your CloudFront origin resources directly. In this case, we will be considering the ALB as a CloudFront origin resource. And we will be enabling the origin access restriction by implementing the custom headers. In this approach, we will be having the custom-header configured at the CloudFront level and adding the condition at ALB. Let's have an architecture to understand more in detail.

Here’s how it works, as shown in the above architecture:

  1. A viewer requests for the content or file by calling the domain name.
  2. Route53 routes the request to a CloudFront edge location that can best serve the request in terms of low latency by serving from the nearest location.
  3. AWS WAF inspects the incoming request according to configured web ACL rules.
  4. CloudFront checks its cache for the requested content. If the content is in the cache, CloudFront returns it to the user. If the content isn’t in the cache, CloudFront adds the custom header with the value of the header configured in the origin's config and forwards the request to the origin. All these communications will happen via HTTPS protocol as we have restricted the Origin Protocol Policy, HTTPS only.
  5. Application Load Balancer (ALB)-Origin, will be having only HTTPS as a listener having a condition applied to allow the only request which comes on port 443 and with proper custom header attached with it otherwise it will block at ALB level and return a static response with status code 403.


This implementation includes the following important steps:

  • We need to make the following changes in the Origins by adding the Origin Custom Headers in the CloudFront.

After making the change it will look like this:

  • As we are running all our workload in Kubernetes at Halodoc, we will be adding the following changes in ingress ALB.

To achieve the above configuration at ingress ALB we will have to make the following changes in the deployment YAML files.

  • We will add or edit the following annotation to allow only HTTPS.

Configure the condition to allow only when a request comes with a custom header attached and this can be achieved by adding the following configurations in ingress.yaml file.

  • Then run the deployment pipeline and validate by hitting the curl command directly to the Origin where we should be getting the static response with the status code 403.

Validate below points post-implementation of the custom header:

  1. Check Origin protocol policy should be HTTPS in CloudFront origin configuration.
  2. Check whether the HTTP port has been closed in ALB.
  3. Custom-header has been added in ALB as a condition.
  4. Check fixed response for default actions in ALB listener.


By implementing this we have secured our public endpoints by adding one more layer of security. We have restricted the control access to the content of the origin by configuring our origin to respond to requests only when they include the custom header that gets added by CloudFront, which prevents the user from bypassing the CloudFront and accessing the content directly. It facilitated us to remove the HTTP listener from ALB which was redirecting to HTTPS before implementation.

Note: We have not used any extra component which will incur extra cost. We have just enhanced the existing service features by implementing this solution.

Join us

We are always looking out for top engineering talent across all roles for our tech team. If challenging problems that drive big impact enthral you, do reach out to us at

About Halodoc

Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek and many more. We recently closed our Series C round and In total have raised around USD$180 million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.

Kailash Singh Adhikari

Senior DevOps Engineer, Expertised in DevOps | Cloud | AWS | CICD | ISTIO | Networking