TL;DR: SSRF is a server fetching a destination an attacker influenced, using the server's network position to reach internal services and cloud metadata credentials. LLM fetch and browsing tools fetch URLs chosen by the model, and the model's choices can be steered by injected text, so the tool is an SSRF primitive by design. Defend in the tool and the network: allowlist destinations where possible, otherwise resolve, reject non-public addresses and connect to the checked address, re-validate redirects, route through an egress proxy with no internal reach, and harden the metadata service (IMDSv2).
How to approach it
Define SSRF with its classic targets, explain why URL string filters fail, then build the defence stack. Then make the AI connection explicit: who chooses the URL, and why that moves enforcement out of the prompt.
A strong answer
Injected text
names an internal URL
Model
calls fetch(url)
Fetch service
inside your network
Internal targets
metadata, admin APIs
Controls in the fetcher
Resolve, then check IP
- Block private, link-local, metadata ranges
Egress proxy
- Allowlist; no redirects to internal
IMDSv2, no creds
- Least-privilege instance roles
Classic SSRF. Features like link previews, webhooks and "import from URL" fetch destinations users supply. Targets: the cloud metadata service (instance credentials), internal APIs and admin panels that trust the internal network, and localhost services. Blind SSRF returns nothing but can still trigger internal actions.
Why filters fail. Blocking strings such as localhost misses decimal and hex IP encodings, IPv6 forms, DNS names pointing at internal addresses, DNS rebinding between check and fetch, and redirects from public URLs to internal ones.
Defence stack.
| Layer | What it does |
|---|---|
| Destination allowlist | Only specific domains, when the feature permits |
| Resolve, validate, pin | Reject any non-public resolved IP; connect to that exact IP |
| Redirect handling | Disable, or re-validate each hop |
| Egress proxy / isolated segment | Fetcher cannot reach internal ranges or metadata at all |
| Metadata hardening | IMDSv2 session tokens and hop limits; equivalents on other clouds |
| Response minimisation | Return only what the feature needs; no raw errors |
Why LLM tools bring it back. In a classic feature, a user types the URL. In an agent, the model decides what to fetch, influenced by everything in its context: user messages, retrieved documents, web pages from earlier fetches, tool results. A page can say "fetch this internal address and summarise it", and a fooled model will request it. That changes three things:
- Enforcement must not depend on the model. A system prompt saying "never fetch internal URLs" is not a control. The tool's validation and the network are.
- The fetcher is also an exfiltration channel. The model can put private data into a URL's path or query, so outbound requests carry data out. Restrict destinations, strip or cap query strings, and log requests.
- Fetched content is untrusted input. Whatever the tool returns enters the model's context and can carry further injection.
Concrete design. Run fetches in a separate service with no cloud credentials, in a network segment that only reaches the internet through a proxy that enforces public-address rules; disable redirects or re-check them; set timeouts and size limits; return extracted text, not raw responses; and log URLs per session.
What interviewers probe next
- "The agent needs to call one internal API too. Now what?" A separate, dedicated tool for that API with its own authorization, never a general fetcher with an internal exception.
- "How would you detect SSRF attempts?" Alert on fetches to non-public addresses, metadata paths and unusual ports at the proxy.
- "What about DNS rebinding?" Pinning the validated IP or proxy-side enforcement at connect time defeats it.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A link-preview feature fetches any URL a user pastes, and the same fetch function powers an AI assistant's browse tool running in a cloud VPC.
Start here
What is server-side request forgery?
What can the server reach that the user cannot?
A server fetching a destination an attacker influenced, using the server's network position to reach internal services and cloud metadata credentials that the attacker cannot reach directly.
Carry it forwardSSRF borrows the server's network position.
Weak answerThinking SSRF only matters for internal web pages.
Constraint changes
Why is an LLM fetch tool an SSRF primitive by design?
Who chooses the URL the tool fetches?
The model chooses URLs, and its choices can be steered by injected text in pages or documents it reads. So an attacker who cannot use the preview feature directly can still make the assistant fetch internal addresses.
Carry it forwardModel-chosen URLs are attacker-influenced.
Weak answerTrusting the model to avoid internal URLs.
Constraint changes
How do you validate destinations properly?
What if DNS changes between check and connect?
Allowlist destinations where possible. Otherwise resolve the name, reject non-public addresses (private, loopback, link-local, metadata), and connect to the resolved address you checked, repeating the check on every redirect.
Carry it forwardResolve, check, connect to the checked IP, recheck redirects.
Weak answerChecking the hostname string only.
Constraint changes
What network-level controls help?
What if the application check has a bug?
Run fetchers in an isolated network segment with an egress proxy that enforces the same rules, block the metadata service from that workload, and give it no credentials. Then a validation bug does not expose internal systems.
Carry it forwardEnforce in the network as well as the code.
Weak answerRunning fetches from the main application network.
Constraint changes
What about the content fetched?
What could a fetched page tell the model?
Limit size and time, do not render or execute it, and treat it as untrusted text for the model, since fetched pages can carry injected instructions. Mark it clearly as data.
Carry it forwardFetched content is untrusted input.
Weak answerFeeding fetched pages to a model with powerful tools.
Now defend it
How would you secure the shared fetcher?
Allowlist where possible; otherwise resolve and reject non-public addresses, connect to the checked IP and recheck on redirects; run the fetcher in an isolated segment behind an egress proxy with metadata blocked and no credentials; limit size and time; and treat fetched content as untrusted input for the assistant.
How it's scored
Weak: Defines SSRF and proposes a blocklist of hostnames or a prompt instruction.
Hire: Explains filter bypasses and resolve-validate-pin plus egress isolation, and notes injection-driven URLs in agents.
Strong Hire: Treats the fetch tool as both an SSRF and exfiltration channel, puts all enforcement outside the model, and designs an isolated fetch service with metadata hardening and logging.
Common mistakes
- Relying on the system prompt to avoid internal URLs.
- Validating the hostname string instead of the resolved address.
- Following redirects without re-validation.
- Running the fetch tool with the application's cloud credentials.