- IDOR vulns are mainly caused by improper access control on the back-end servers
# Object-Level Access Control
- User roles and permissions are a vital part of any access control system, which is fully realized in a Role-Based Access Control (RBAC) system
- To avoid exploiting IDOR vulnerabilities, we must map the RBAC to all objects and resources
- The back-end server can allow or deny every request, depending on whether the requester's role has enough privileges to access the object or the resource
- Example code for a web app to compare user toles to object and allow/deny
```javascript
match /api/profile/{userId} {
allow read, write: if user.isAuth == true
&& (user.uid == userId || user.roles == 'admin');
}
```
# Object Referencing
- While the core issue with IDOR lies in broken access control (`Insecure`), having access to direct references to objects (`Direct Object Referencing`) makes it possible to enumerate and exploit these access control vulns
- To this end, we should never use object references in clear text or simple patterns (e.g. `uid=1`)
- We should always use strong and unique references, like salted hashes or `UUID`'s
- Example php code mapping UUIDs to objects
```php
$uid = intval($_REQUEST['uid']);
$query = "SELECT url FROM documents where uid=" . $uid;
$result = mysqli_query($conn, $query);
$row = mysqli_fetch_array($result);
echo "<a href='" . $row['url'] . "' target='_blank'></a>";
```