# Insecure Direct Object Reference (IDOR) allows access to another user's data via predictable IDs

- **ID:** `security/insecure-direct-object-reference-in-api`
- **Domain:** security
- **Category:** auth_error
- **Error Code:** `AUTH_IDOR_006`
- **Verification:** ai_generated
- **Fix Rate:** 88%

## Root Cause

The API exposes internal object IDs (e.g., user ID, order number) in URLs or request bodies without verifying that the authenticated user owns the resource, allowing unauthorized access to other users' data.

## Version Compatibility

| Version | Status | Introduced | Deprecated |
|---------|--------|------------|------------|
| REST API | active | — | — |
| GraphQL | active | — | — |
| Spring Boot 3.1 | active | — | — |

## Workarounds

1. **Implement authorization checks on every API endpoint that accesses a resource by ID. Example in Node.js/Express:
app.get('/api/order/:id', async (req, res) => {
    const order = await Order.findById(req.params.id);
    if (!order || order.userId !== req.user.id) {
        return res.status(403).json({ error: 'Forbidden' });
    }
    res.json(order);
});** (90% success)
   ```
   Implement authorization checks on every API endpoint that accesses a resource by ID. Example in Node.js/Express:
app.get('/api/order/:id', async (req, res) => {
    const order = await Order.findById(req.params.id);
    if (!order || order.userId !== req.user.id) {
        return res.status(403).json({ error: 'Forbidden' });
    }
    res.json(order);
});
   ```
2. **Use attribute-based access control (ABAC) with a policy engine (e.g., OPA) to centrally enforce that users can only access resources they own.** (85% success)
   ```
   Use attribute-based access control (ABAC) with a policy engine (e.g., OPA) to centrally enforce that users can only access resources they own.
   ```
3. **Replace direct object IDs with opaque, non-guessable tokens (e.g., signed JWTs) that encode the user's identity and resource ownership, and validate the signature on each request.** (88% success)
   ```
   Replace direct object IDs with opaque, non-guessable tokens (e.g., signed JWTs) that encode the user's identity and resource ownership, and validate the signature on each request.
   ```

## Dead Ends

- **Obfuscate object IDs by using hashes (e.g., MD5) instead of sequential numbers** — Obfuscation is not authorization; if the hash is leaked or guessed (e.g., via enumeration), access is still granted. Authorization checks are required. (95% fail)
- **Use UUIDs instead of integers for IDs** — UUIDs make guessing harder but do not prevent access if a user obtains another user's UUID (e.g., via shared links or logs). Authorization is still missing. (90% fail)