Amazon S3 static website hosting

`Server: AmazonS3` — weight 90.

An `x-amz-request-id` or `x-amz-bucket-region` header — weight 70.

A bucket URL on `amazonaws.com` in the markup — weight 55, which shows the site loads files from S3 without proving the page itself is served from it.

It is reported as an S3 detection, never as proof that the rest of the infrastructure runs on AWS.

The S3 documentation states that website endpoints do not support HTTPS, and points to CloudFront for serving an S3-hosted static website over HTTPS.

A custom domain pointing straight at a website endpoint can therefore only be served over plain HTTP.

An HTTPS site built on S3 has a CDN or proxy in front, and that layer is what an audit's transport checks describe.

A site found answering only over HTTP from S3 is usually missing that layer.

Website endpoints follow a Region-specific format — `bucket-name.s3-website-Region.amazonaws.com` or, in some Regions, `bucket-name.s3-website.Region.amazonaws.com` — and the documentation writes them with `http://`.

The documentation's comparison of endpoints is precise: at the root of a bucket, the REST endpoint returns a list of the object keys, while the website endpoint returns the configured index document.

A publicly readable bucket reached through the REST endpoint therefore lists every file name it contains, including files nobody linked to.

That is the S3 form of a directory listing, and it is reported like one.

Account-level Block Public Access settings are how AWS lets owners prevent public access regardless of individual bucket policies.

It proves a response or an asset came from S3.

It does not show the bucket's policy, its Block Public Access configuration or its region beyond what a header states.

It does not show whether other buckets exist or what they contain; none are ever enumerated.

Files loaded from an S3 bucket by a page on another host prove only that the bucket serves those files publicly.

`technology.aws` reports the S3 and CloudFront products observed, with the caveat that it says nothing about the rest of the infrastructure.

`infrastructure.cloud_provider` and `infrastructure.hosting` place the detection among the other infrastructure signals.

`transport.https` and `transport.http_redirect` report whether HTTPS is served at all.

`wordpress.directory_listing` and the listing problem page cover listings; an S3 key listing is reported in the same terms.

The S3 documentation contrasts the two endpoints directly: the website endpoint supports only publicly readable content, while the REST endpoint supports public and private content.

Errors differ too: the REST endpoint returns XML error responses, the website endpoint returns an HTML document.

Only the website endpoint supports object- and bucket-level redirects, and it accepts only GET and HEAD requests on objects.

An XML error body on a site's pages is therefore a sign it is being served from the REST endpoint — the one that lists keys at the bucket root.