不安全直接对象引用问题发生在应用程序基于用户提供输入来进行直接对象引用过程的时候。通过这个漏洞攻击者能绕过授权过程，直接访问系统资源，例如数据库记录或文件。
不安全的直接对象引用允许攻击者通过修改指向对象的参数值来直接操纵对象，从而绕过授权过程。这些对象可以是其他用户的数据库表单项、系统文件或其他东西。这种问题的产生原因是应用程序采用用户提供的输入，并使用这些输入来绕过授权检查来获得对象资源。
测试者首先需要找出应用程序中所有直接引用对象的用户输入的位置。例如，用户输入被用于访问数据库数据行、文件和应用页面的地方等等。接下来测试者应该修改这些应用直接对象的值来判断是否能获得属于其他人的资源，也就是绕过授权过程。
测试直接对象应用最佳的办法需要最少两个（通常更多）用户来覆盖不同所有权和函数功能。例如两个用户访问不同的内容对象（比如购买信息、私人消息等等）和（相关的）不同权限用户（比如管理员用户）来查找是否有直接引用的对象。通过使用多个用户，测试者能够节约宝贵的测试时间用来猜测不同的对象名词，他们可以直接尝试访问数据其他用户的对象。
下面是一些典型的漏洞场景和每一种测试方法：
直接获得数据库数据的参数值
请求样本：
http://foo.bar/somepage?invoice=12345
在这个例子中，invoice参数值被用于索引数据库中的发票表。应用程序接受参数值并用于数据库查询。应用程序返回发票信息给用户。
由于invoice的值直接被用于查询中，通过修改这个参数可以获取任何发票对象，无视其拥有对象。为了测试这个案例，测试者应该获得一个属于其他测试用户的发票对象标识（确保在应用程序业务逻辑中这个对象是不应该被查看的），并检查是否可能绕过授权过程来访问该对象。
直接实施系统操作的参数值
请求样本：
http://foo.bar/changepassword?user=someuser
在这个案例中，user参数值被用于告诉应用程序应该修改哪个用户的密码。在许多案例中这可能是向导中的一部分或者多个步骤操作中的一部分。在最初的步骤中应用程序会获得修改用户密码的请求，在下一个步骤中用户会提供一个新密码（并不询问当前密码）。
user参数被直接用于标识将要修改密码操作的用户对象。为了测试这个案例，测试者应该尝试提供一个不同测试用户的用户名，并检查是否能修改其他用户的密码。
直接获得系统文件资源的参数值
请求样本：
http://foo.bar/showImage?img=img00011
在这个例子中file参数值被用于告诉应用程序用户需要获取那个文件。通过提供不同名称或标识的文件（比如file=image00012.jpg），攻击者可能能够获得属于其他用户的文件。
为了测试这个案例，测试者应该获得一个该用户不应该能访问的对象标识，并将他作为file参数值来获取这个对象。注意：这个漏洞经常被结合目录/路径遍历漏洞中一起利用（参见相关[测试目录遍历章节]）。
直接访问应用程序功能函数的参数值
请求样本：
http://foo.bar/accessPage?menuitem=12
在这个例子中，menuitem参数值被用于告诉应用程序用户希望访问哪个目录项（某个应用功能对象）。假设用户被限制，只有访问目录项1、2和3的链接。通过修改menuitem参数值，可能绕过授权过程并使用额外的程序功能。为了测试这个案例，测试者需要鉴别决定目录项的位置（功能），找出测试用户能使用的所有功能被尝试访问其他功能。
在上面这些例子中，修改单个参数就能起到很大作用。然而有时候对象引用可能被分割为多个参数，测试者需要做出相关调整。