Cloudfront supports adding external origins, i.e. domains that are not S3 buckets or ALBs. This led me to wonder whether adding domains that are not owned by the entity as an origin could allow for intercept the request payload, and potentially act as an Man in the Middle Attack.
Let's say I have a REST API running on ECS behind an Application Load Balancer(ALB) on AWS. The ALB is fronted by a cloudfront domain, called abcd.cloudfront.net. As one would expect, there's a CNAME record setup on the DNS provider called app.mysite.com pointing to the cloudfront domain with a valid SSL cert from ACM. The ALB has a rule to only allow requests that have the header HOST:app.mysite.com. This create a pretty standard API flow on AWS.
What would happen if someone, with no access to my AWS account, sets up a new cloudfront domain, abcd2.cloudfront.net with the domain app.fake-mysite.com and valid ACM cert for app.fake-mysite.com, and adds a behavior to point to app.mysite.com. Can this external entity use it's own ACM cert to cause a Man in the Middle Attack?
The request flow would look like this:
app.fake-mysite.com -> abcd2.cloudfront.net -> app.mysite.com -> abcd.cloudfront.net -> my-alb.domain -> 10.0.0.100:8080 (REST API)
Would it be possible for the external entity to intercept the request at the first hop and capture the encrypted data? If so, how can this be prevented?
As far as the REST API container is concerned, the request would have originated from the app.mysite.com, and would be completely unaware of this wrapper cloudfront distribution (app.fake-mysite.com)
Note: I had initially asked this question on Stackoverflow, and I was told this is a better place to discuss this.