IDOR and SSRF
Change one number to read someone else's data, or make the server fetch for you.
What you will learn
- -Find and test an insecure direct object reference
- -Explain how SSRF turns a server into your proxy
- -Recognize why these bugs bypass the network perimeter
Some of the most damaging web bugs need no exotic at all. You change a number, or you hand the a , and it hands back data it should never have given you. This lesson covers two broken-access- classics: and .
IDOR: the app trusts your ID
An Insecure Direct Object Reference happens when an app uses a value you control (an ID in the URL, a hidden form field, a ) to fetch a record, but never checks that the record belongs to you. You see:
GET /api/invoice?id=1024
You are user 1024. You change it to 1023, and the server returns someone else's
invoice. The was fine, you were logged in, but the
was missing. The app confirmed who you are and forgot to check
what you are allowed to see.
Testing it is exactly as blunt as it sounds:
$curl -H "Cookie: session=YOURS" "http://target/api/invoice?id=1024"$curl -H "Cookie: session=YOURS" "http://target/api/invoice?id=1023"$for i in $(seq 1000 1030); do curl -s "http://target/api/invoice?id=$i"; doneNever trust that an ID belongs to the caller. On every request, the server must check 'does this session own this object' before returning it. Swapping numeric for random UUIDs only hides the door. It does not lock it. Enforce ownership, do not just obscure the key.
SSRF: the server fetches for you
Server-Side Request Forgery is when an app takes a URL from you and makes the request itself. Think of a feature like 'import image from URL' or a webhook tester. You give it a URL, and the server, sitting inside the trusted , fetches it.
That is powerful because the server can reach places you cannot. The that blocks you from internal does not block the server. You point it inward:
POST /fetch url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
On many cloud hosts, 169.254.169.254 is the metadata service. An SSRF that
reaches it can leak temporary cloud . Other SSRF targets: internal
admin panels on 127.0.0.1, databases on private , other services behind the
perimeter.
Why these bypass the perimeter
Both bugs live above the network layer. Your firewall and segmentation assume the attacker is outside. IDOR lets an authenticated outsider read inside data. SSRF borrows the server's position inside the trusted zone. The path an SSRF takes looks like the server reaching across the internal network on your behalf.
src 10.0.0.5:51820src 203.0.113.7:40311dst 93.184.216.34:443Allowlist the exact outbound destinations the feature needs. Block requests to
private and link-local ranges (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16).
Resolve the hostname and validate the resolved IP, because http://localhost and
rebinding both dodge naive string checks.
You are logged in as your own account but can read invoice id=1023 by changing the URL. What is missing?
On a cloud VM, which IP address is the classic SSRF target for stealing instance credentials?
The link-local metadata 169.254.169.254 serves instance metadata, including temporary credentials, to anything that can reach it from the host.