What a storefront scan may reach

The storefront scan fetches the merchant's declared website and reports what came back — status, final URL, title, platform, payment providers on the page, which disclosures are visible, and which configured prohibited terms appear in the text.

That last one is an arbitrary substring oracle over the response body. Which makes this a request whose target the outside world chooses and whose answer comes back to a screen.

The gate

Every outbound request the scan makes — the page, each redirect, and robots.txt — goes through one check. Four rules, and each closes a way round the others.

Resolve first, judge the address	internal.corp and metadata.example.com are ordinary names that resolve wherever their owner points them. Judging the hostname decides nothing
Deny by explicit range	Private space, loopback, link-local (including the cloud metadata address), carrier-grade NAT, multicast, reserved. Written out rather than derived
Pin the connection	We connect to the address that was checked, keeping the hostname for certificate verification — so DNS cannot answer differently between validating and dialling
Every hop	A redirect target is a fresh destination and goes through all of the above

This was not an insider risk

The scan followed redirects and re-checked only that the target was http(s). So it needed no account at all: a merchant submits a genuine storefront, we scan it exactly as designed, and their server answers 302 to http://169.254.169.254/latest/meta-data/.

On a host with an instance role, that is cloud credentials. On any host, it is whatever is listening inside the network — and the response comes back through the prohibited_terms_present field.

Refusing is an outcome, not an error

A merchant whose site redirects into private address space is a fact about that merchant, and the operator needs to see which URL did it. So the scan records blocked_destination with the reason, rather than failing as though the call broke.

There is no port allowlist

Deliberately. The address decides this: a service worth reaching on an odd port is on a private address and already refused, and a public host's open ports are reachable by anyone with a socket. A storefront on :8443 has always been supported and still is.

When the scan leaves the declared host

A redirect to another public host is ordinary on the web and is followed. But the scan records that it left, and prohibited_terms_present is withheld when it did.

Over a response we did not intend to fetch, that field is an oracle rather than a finding about a storefront — it would say nothing true about this merchant.

What the scan is, and is not

An underwriting aid. It reads one page, follows no links, identifies itself honestly, consults robots.txt and refuses rather than fetching what it was asked not to, and caps what it will read.

It is not a scheme content scan, and nothing in Verity treats it as one.