SSRF and IDOR

Authorization first: this is a defender’s autopsy

Everything below assumes a signed engagement with explicit scope — a deliberately vulnerable lab, a CTF, your own application, or a bug-bounty program with the target in scope. Pointing a server’s request feature at a cloud metadata endpoint you don’t own, or iterating object ids in an application you have no authorization for, is unauthorized access in most jurisdictions, full stop. Reading another user’s record is a privacy breach even if you “only looked.” We study the attacker’s reasoning for one reason: you cannot reliably close a vulnerability class you understand only as a checklist line. Read this as the autopsy a defender performs on their own code — learning to see the request and the query the way the attacker does, so the control is in the design before the bug ever ships. No copy-paste payloads here, only the mechanism.

SSRF: the server as a confused deputy

Server-side request forgery happens when an application takes a URL (or hostname, or IP) influenced by the user and makes an outbound request to it — a “fetch this image,” “import from this webhook,” “preview this link,” or “validate this RSS feed” feature. The attacker’s input never reaches the internal target directly; instead they trick the server into reaching it. This is the classic confused deputy: the server has privileges and network position the attacker lacks — it sits inside the VPC, can resolve internal DNS, holds an IAM role — and the attacker borrows all of it by choosing where the server points.

The mechanism has two ingredients. First, the request destination is attacker-influenced and the server doesn’t constrain it to a known-good set. Second, the network the server lives in contains something worth reaching that the attacker cannot reach from outside: a cloud instance metadata service, an internal admin panel on a private IP, a database that only accepts connections from the app tier, a Kubernetes API on a cluster IP. The textbook prize is the cloud metadata endpoint at the link-local address 169.254.169.254, which on a misconfigured instance hands out the machine’s IAM role credentials to anything that asks from on-box. SSRF reaches it because the request now originates on-box.

The attacker’s reasoning is a series of probes. Does the feature follow redirects (so an allowlisted host can 302 to an internal one)? Does it resolve DNS at fetch time (so a name that resolves to a public IP during validation can re-resolve to 127.0.0.1 at fetch — a DNS-rebinding race)? Does it accept non-http schemes like file://, gopher://, or dict:// that turn a fetch into a file read or a raw-socket write to Redis? Each answered “yes” is another way past a naive defense. This is why SSRF earned a spot on the OWASP Top 10 by practitioner vote despite thin historical data — cloud architectures made the blast radius enormous: one fetch feature can become full cloud-account compromise.

IDOR: a missing ownership check

Insecure Direct Object Reference is the production face of Broken Access Control. The server exposes a reference to an internal object — most often a database row id in a URL like /api/orders/7741 — uses that client-supplied value to look up the object, and never checks that the caller is allowed to see this particular object. The query is SELECT … WHERE id = ? when it needed to be SELECT … WHERE id = ? AND owner_id = ?. The attacker’s “exploit” is incrementing an integer. There is no payload, no special tooling: a valid session plus a guessable id is the whole attack.

The crucial reframing is that IDOR is authorization, not authentication. The attacker is fully logged in as themselves — that’s the point. Authentication asks “who are you?” and the session answers it correctly. Authorization asks “are you allowed to touch this object?” and the vulnerable code never asks it at all; it silently assumes a valid session implies permission for any id you can name. Object references leak constantly — in URLs, logs, referer headers, shared links, prior API responses — so “make the ids random UUIDs” only raises the guessing cost; it does not add the missing check. That is the senior trap to avoid: unguessable identifiers are obfuscation, not access control.

Same root, mirrored shape

Put SSRF and IDOR side by side and the symmetry is the lesson. In both, the server takes a value from the client and acts on it without enforcing the boundary it implies. IDOR trusts an object reference to mean “you may read this object.” SSRF trusts a URL to mean “you may fetch this resource.” Both substitute an unverified client-supplied value for a server-side authorization decision. The table makes the parallel explicit.

How a defender closes both

For IDOR, the fix is structural, not cosmetic: enforce authorization server-side on the actual object and action, every time, computed from server-side session state — never inferred from a hidden UI element or a client-supplied claim. In a query that means scoping to the owner (WHERE id = ? AND owner_id = ?) or running an explicit policy check before returning the row. Centralize it so a new endpoint can’t forget it, and treat object-level authorization as the default every handler inherits.

For SSRF, defense is layered because no single control is sufficient. Constrain the destination to an allowlist of permitted hosts/schemes, resolve the hostname and validate the resolved IP against blocked ranges (link-local 169.254.0.0/16, loopback, RFC-1918 private space, cloud metadata IPs), and re-check after every redirect — validating the string alone loses to DNS rebinding and redirects. Then assume a control will eventually fail and harden the target: require a session-token metadata service (IMDSv2-style, which blocks the simple GET that classic SSRF relies on), give the instance the least IAM privilege it needs, and place egress firewall rules so the app tier simply cannot open arbitrary outbound connections. The recurring senior reflex across both bugs is the same: deny by default, verify the boundary server-side, and never let an unverified client value stand in for an authorization decision.