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, which sits at the top of the 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 reviews a frequent place to find IDOR.

In a Trickest 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.