Insecure Direct Object Reference

Direct object reference vulnerabilities occur when there are insufficient authorization checks performed against object identifiers used in requests. This could occur when database keys, filenames, or other identifiers are used to directly access resources within an application. These identifiers would likely be predictable (an incrementing counter, the name of a file, etc), making it easy for an attacker to detect this vulnerability class. If further authorization checks are not performed, this could lead to unauthorized access to the underlying data.

GitHub heavily uses the ActiveRecord ORM within Rails when accessing objects. While ActiveRecord can be used in a way to directly access objects via their database ID, this usage is atypical. Instead, objects are usually referenced using the ActiveRecord API, which defines relationships using associations such as has_many or belongs_to. Used consistently, ActiveRecord can reduce accidental direct object reference by implicitly querying objects that that have been associated with the current_user, organization, or other authenticated entities.

More about direct object reference vulnerabilities from OWASP’s Top 10:

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.