One of your services fetches a URL supplied by the user — for previews or webhooks. Walk me through why that's dangerous in the cloud and how you'd defend it properly.

technical-conceptual · Senior level · cloud-devops-security

What the interviewer is really asking

Assesses whether the candidate understands SSRF — especially the cloud-specific escalation to the instance metadata endpoint to steal credentials (the Capital One pattern) — and can layer real defenses: allowlisting over denylisting, enforcing IMDSv2 and disabling IMDSv1, and network egress controls, rather than blocking obvious internal IPs.

What to say

• Explain the cloud escalation, not just generic SSRF: a server that fetches a user-supplied URL can be coerced into requesting internal endpoints — and in the cloud the worst target is the instance metadata service, where SSRF can read the workload's credentials, which is exactly the Capital One breach pattern.
• Defend at the application layer with allowlisting: validate the destination against an allowlist of permitted domains rather than trying to denylist internal IPs, resolve and re-check the address to defeat DNS-rebinding, and block redirects to disallowed hosts — denylists are routinely bypassed.
• Add cloud and network defense-in-depth: enforce IMDSv2 (session-token, PUT-based, hop limit) and disable IMDSv1 so a basic SSRF can't read metadata, and restrict the service's outbound egress so it can only reach the destinations it legitimately needs.

What to avoid

• Treating it as a generic input-validation issue and missing the cloud metadata-credential-theft escalation that makes SSRF catastrophic.
• Relying on a denylist of internal IP ranges, which is bypassable via DNS rebinding, redirects, alternate IP encodings, and IPv6 — allowlisting is the defensible approach.
• Enabling IMDSv2 but leaving IMDSv1 available, which provides no protection because the instance still answers the unauthenticated v1 requests an SSRF uses.

Example answers

Strong: The cloud danger isn't just hitting an internal service — it's that the server can be steered at the instance metadata endpoint and made to read the workload's credentials, which is the Capital One pattern. So at the app layer I allowlist the destinations the feature is actually allowed to fetch rather than denylisting internal IPs, because denylists fall to DNS rebinding, redirects, and weird IP encodings — and I re-resolve and re-check the address and refuse redirects to non-allowlisted hosts. Then defense-in-depth: enforce IMDSv2 and actually disable IMDSv1, so a basic SSRF can't read metadata at all, and lock the service's egress to only what it needs.

Weak: I'd validate the URL and block requests to localhost and the private IP ranges like 10.x and 192.168.x so it can't hit our internal network, and make sure the input is a well-formed URL before we fetch it. That stops it from reaching internal services.