Probe safety: read-only methods, private ranges refused
The probe fetches your deployed application from the outside, the way a visitor’s browser would. That makes it powerful for finding what is genuinely exposed — and it makes restraint a safety requirement, because a fetcher pointed carelessly at infrastructure could probe networks it was never meant to reach.
Two hard rules govern every request: the method set is fixed and tiny, and the target address is checked against private ranges immediately before connecting, then checked again on every redirect hop.
Read-only methods, enforced at the layer that sends them
The probe speaks GET, HEAD and OPTIONS and refuses to issue anything else. The refusal lives in the fetch layer itself, not in the calling code, so no future feature can accidentally ship a POST. The worst outcome of a probe run is identical to a visitor pressing refresh repeatedly.
Method discipline also bounds blast radius. Read-only requests cannot create records, trigger webhooks, consume mutation quotas or appear in audit trails as writes; they are indistinguishable from ordinary traffic in every respect that matters to your application’s integrity. The trio is sufficient for inspection — fetch a page, check a header, learn what a cross-origin caller would be told — and excludes every verb that could create, change or delete anything.
Private addresses refused, per hop
Before any connection is opened, the resolved target address is checked against the ranges that must never be probed: loopback, the RFC1918 private blocks, link-local, the CGNAT range and cloud-metadata addresses such as the link-local endpoint instance metadata services expose. A hit ends the request before a packet is sent.
The check repeats on every redirect hop. Redirects and DNS can walk a request from a public hostname toward an internal address mid-flight — the classic path by which an innocent-looking fetcher becomes a confused deputy against internal infrastructure. Re-checking per hop closes it: each hop is treated as a brand-new decision, with the same refusal list applied.
The effect is that the probe cannot be aimed at your internal network, your cloud control plane, or anyone else’s — not by a misconfigured project URL, and not by a redirect chain planted to bounce it somewhere unwelcome.
Bounded time, bounded depth
Runs operate inside a wall-clock budget, and the report states plainly if the budget expired before every table was exercised. Fetches follow the page and its scripts to a bounded depth, and everything the probe learns comes from material your application already publishes to strangers.
Budgets and bounds are reported rather than hidden: a report that ran out of time says so, which matters more than a confident-looking green tick covering an unfinished pass. Together these limits keep the probe honest in both directions — it cannot do too much to your infrastructure, and it cannot pretend to have covered ground it never reached.
Related questions
- Can the probe reach services on my internal network?
- No. Loopback, private, link-local, CGNAT and cloud-metadata addresses are refused before connecting, and the refusal is re-evaluated at every redirect hop.
- Could a redirect be used to make the probe attack a third party?
- No. Each hop passes the same address screening as the original URL, so a chain that wanders toward a disallowed target is cut at the hop where it wanders.
Did this answer your question? If not, tell us what is missing — article corrections go straight to the person who maintains it.