Your application uses session ID in cookie to manage session. As you can find in OWASP Cheat Sheet Series:
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a name=value pair.
If your application uses cookie to manage session:
- User A's session ID -> logged in as User A
- User B's session ID -> logged in as User B
If you use user B's session ID and you see user A's account that can be a vulnerability, but did you set enforcement detector filters correctly? Autorize need to know how to assess results correctly. More about enforcement detector configuration https://github.com/portswigger/autorize:
The enforcement detector filters will allow Autorize to detect authentication and authorization enforcement in the response of the server by content length or string (literal string or regex) in the message body, headers or in the full request.
Did you check in "Request/Response Viewers" that your request was really sent with user B's cookie?
For Burp there is also Auth Matrix extension that can help you with IDOR vulnerabilities. I personally find this extension more user-friendly (but the functionality of course is very similar).