[wheaties]

This should be something added to an AWS Security Hub check, e.g. do you have Route53 pointed to an unregistered domain. Otherwise, I can't find fault with AWS at all. Now I have to review our domains on Monday.

[toomuchtodo]

Please bug your TAM if you have one about this. I’ve bugged ours. S3 should not serve a bucket as a website without domain verification. In the interim, we’ve built middleware where a bucket serving content can’t be removed until the dns record has been.

[ctvo]

Or use CloudFront with an S3 bucket as backing for this use case, like you'd expect? CloudFront has domain name verification.

[manigandham]

The point is that without domain verification, it won't stop someone else from registering that bucket (which is what happened with the domains in this article).

[ctvo]

The point is that S3 isn't a CDN. If you use it as a CDN, it's on you to ensure it'll work for your use case. CloudFront, however, is a CDN, and as expected, has domain verification.

[manigandham]

Whether it's a CDN is irrelevant. This is already a supported use-case for S3 which is why it even has this functionality.

It's one of many products that supports serving under custom hostnames and all such products should have domain verification.

[ctvo]

I take it back. S3 outlines this exact use case: https://docs.aws.amazon.com/AmazonS3/latest/userguide/IndexD...

Because of this, I agree, they should verify domain ownership to help protect their users.

[phamilton]

I've seen this attack with cloudfront and an S3 bucket.

You can verify your domain is going to a cloudfront you own, but it doesn't verify that the origin is a bucket you own.