---
title: "Insecure Direct Object Reference"
canonical: https://trickest.com/glossary/idor
description: "An insecure direct object reference lets a user access another user's data by changing an identifier in a request, because the application checks the reference but not authorization."
---

# Insecure Direct Object Reference

An IDOR appears when an application exposes a reference to an internal object, such as a database row ID in a URL or request body, and trusts that reference without checking whether the current user is allowed to access it. Change /account/1043 to /account/1044 and the server hands back another customer's record. The flaw lives in authorization: the user is logged in, yet they reach data that should be off limits.

IDOR is a specific case of [broken access control](/glossary/broken-access-control), which sits at the top of the [OWASP Top Ten](/glossary/owasp-top-ten). It matters because the impact is direct and the bar is low. No exotic payload is needed, just an attacker who increments an ID or replays a request with a different token. The damage scales with the data behind the reference, from a single profile to bulk export through a predictable parameter.

APIs are a common home for these bugs, since they expose object identifiers freely and developers assume the front end is the only caller, which makes [API security](/glossary/api-security) reviews a frequent place to find IDOR.

In a Trickest [web application security](/glossary/web-application-security) workflow, you automate the tedious part: crawl endpoints, capture parameters that look like object IDs, then replay requests across two authenticated sessions and diff the responses to flag access that should be denied.

---
_Markdown source of https://trickest.com/glossary/idor._