Challenge: a safe webhook fetcher

The previous three lessons gave three layers: an application-layer allowlist, network-layer egress, and treating responses as untrusted input. This lesson combines them in the hardest case: a feature where a hostname allowlist is unavailable.

The situation. Product wants a feature: a user pastes the URL of a CSV file and the system imports from it. The URL can be anywhere — Google Drive, Dropbox, a customer's S3 bucket, a customer's internal server exposed to the Internet.

Which means ssrf-allowlist's hostname allowlist does not apply: you cannot know the hostnames in advance. This is not an unreasonable requirement — it is the ordinary requirement of every "import from URL" feature, and it is why this is a challenge.

What to produce.

1. Design the fetch flow. How do you keep the feature without lending an attacker your network position?
2. Name three places a naive implementation breaks, and which layer each needs.
3. State what you cannot stop and why you accept it.

Question 3 is what counts. A security design that does not state its limits is one its users will over-trust.