How to Prevent IDOR Vulnerabilities in Django REST APIs
An authenticated user changes /api/orders/42/ to /api/orders/43/ and reads someone else’s order. No privilege escalation needed — the endpoint just returns it. This is IDOR in its simplest form, and it’s endemic in Django REST Framework code because DRF makes it trivially easy to wire up a ModelViewSet that exposes every object in a table. The authentication layer does its job; the authorization layer was never written.
How IDOR Attacks Work Against Django REST APIs
IDOR (Insecure Direct Object Reference) happens when an API accepts a user-controlled identifier — a URL path segment, query param, or request body field — and retrieves the corresponding object without verifying that the requesting user has any right to it. Authentication proves who you are. Authorization proves what you can touch. Most IDOR bugs exist because the first check was implemented and the second was skipped.
A typical attack against a vulnerable DRF app:
- Attacker authenticates as
alice@example.com and creates an order. The response contains {"id": 101, ...}.
- Attacker sends
GET /api/orders/100/. The API returns Bob’s order because nothing checks ownership.
- Attacker scripts a loop from ID 1 to 10000, dumps every order in the database. Sequential integer PKs make enumeration take seconds.
Here is the vulnerable ViewSet pattern we see most often in real codebases:
# views.py — VULNERABLE
from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated
from .models import Order
from .serializers import OrderSerializer
class OrderViewSet(viewsets.ModelViewSet):
serializer_class = OrderSerializer
permission_classes = [IsAuthenticated] # proves identity, not ownership
def get_queryset(self):
# Returns every order in the database — any authenticated user
# can retrieve, update, or delete any order by guessing its PK.
return Order.objects.all()
IsAuthenticated blocks anonymous requests, which makes it look like the endpoint is secured. But any valid session token — including one the attacker registered themselves — bypasses it. The retrieve(), update(), and destroy() actions in ModelViewSet all call get_object(), which calls get_queryset() and then filters by the URL pk. Since get_queryset() returns everything, get_object() happily resolves any ID.
Fixing IDOR by Scoping Querysets to the Authenticated User
The correct fix is to scope get_queryset() to the authenticated user so that the object simply doesn’t exist from the API’s perspective if it doesn’t belong to the requester. This gives you a 404 instead of a 403, which is almost always the right behavior — a 403 confirms the resource exists and leaks information about the ID space.
Add a second layer with a custom BasePermission that implements has_object_permission. The queryset filter handles list and retrieve; the object permission handles mutating actions where DRF calls check_object_permissions explicitly.
# permissions.py
from rest_framework.permissions import BasePermission
class IsOwner(BasePermission):
def has_object_permission(self, request, view, obj):
# Explicit ownership check — queryset scoping is the first line,
# but we defend in depth for any path that bypasses get_queryset.
return obj.owner == request.user
# views.py — FIXED
from rest_framework import viewsets
from rest_framework.permissions import IsAuthenticated
from .models import Order
from .serializers import OrderSerializer
from .permissions import IsOwner
class OrderViewSet(viewsets.ModelViewSet):
serializer_class = OrderSerializer
permission_classes = [IsAuthenticated, IsOwner]
def get_queryset(self):
# Scope to the requesting user at the ORM layer — objects that don't
# belong to this user never enter the retrieval pipeline at all.
return Order.objects.filter(owner=self.request.user).select_related("owner")
def perform_create(self, serializer):
# Bind the new object to the authenticated user so the POST path
# can't accept a user-controlled owner field.
serializer.save(owner=self.request.user)
Filtering at the queryset layer beats checking IDs inside the view body for two reasons. First, it’s impossible to forget: every action — list, retrieve, update, partial update, destroy — goes through get_queryset(). Second, it eliminates a whole class of time-of-check / time-of-use bugs where you check ownership in get but forget to re-check in patch.
The same defense-in-depth principle applies to object-level auth in gRPC services and any RPC-style API where the framework doesn’t give you a queryset abstraction: filter first, check permissions on the resolved object second.
Use Unguessable Identifiers Instead of Sequential IDs
Sequential integer PKs are an enumeration gift. Once an attacker has one valid ID, they have a roadmap to every other record. Replacing exposed identifiers with UUIDs or opaque slugs doesn’t fix the authorization hole — that requires the fixes above — but it raises the cost of bulk enumeration from “write a loop” to “brute-force a 128-bit space.”
# models.py
import uuid
from django.db import models
class Order(models.Model):
# Use UUIDField as the primary key to prevent sequential enumeration.
# This is defense in depth — queryset scoping is still mandatory.
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
owner = models.ForeignKey(
"auth.User", on_delete=models.CASCADE, related_name="orders"
)
total = models.DecimalField(max_digits=10, decimal_places=2)
created_at = models.DateTimeField(auto_now_add=True)
# urls.py — router uses the UUID field as the lookup
from rest_framework.routers import DefaultRouter
from .views import OrderViewSet
router = DefaultRouter()
router.register(r"orders", OrderViewSet, basename="order")
# Override lookup_field on the ViewSet to match the UUID primary key
# so DRF resolves /api/orders/<uuid>/ instead of /api/orders/<int>/
# views.py addition
class OrderViewSet(viewsets.ModelViewSet):
lookup_field = "id" # matches the UUIDField name on the model
# ... rest of ViewSet unchanged from the fix above
One tradeoff: UUIDs inflate index size and can slow joins on large tables. If that matters, use a separately-stored public_id = models.UUIDField(default=uuid.uuid4, editable=False, unique=True) alongside an integer PK, and expose only public_id in serializers and URLs. The internal integer PK never appears in any HTTP response.
Never treat opaque IDs as a substitute for proper authorization. We’ve reviewed APIs that switched to UUIDs, removed the queryset scoping because “users can’t guess them now,” and then leaked UUIDs in webhook payloads, browser history, or third-party analytics — instantly making every ID known to an attacker.
Enforce Authorization at the Serializer and Nested Resource Level
Queryset scoping protects URL-path-based access. IDOR also hides in writable foreign key fields where a user submits a payload referencing another tenant’s object. A user who owns projects 10 and 11 might try {"project": 99} on a task creation endpoint to attach their task to someone else’s project.
This is especially common in multi-tenant SaaS applications where related resources belong to different organizational boundaries.
# serializers.py
from rest_framework import serializers
from .models import Task, Project
class TaskSerializer(serializers.ModelSerializer):
class Meta:
model = Task
fields = ["id", "title", "project", "due_date"]
def validate_project(self, value):
request = self.context.get("request")
if request is None:
raise serializers.ValidationError("No request context available.")
# Reject foreign keys that don't belong to the authenticated user —
# without this check, any user can write into any project by ID.
if not Project.objects.filter(id=value.id, owner=request.user).exists():
raise serializers.ValidationError(
"Project not found." # Deliberately vague — don't confirm existence
)
return value
Always pass request in serializer context. DRF does this automatically when you use get_serializer() inside a view, but if you instantiate serializers directly (in management commands, signals, or background tasks), you must pass context={"request": request} manually. When there’s no request context at all — background jobs, for example — you need a different mechanism to establish the authorization boundary, typically passing the owner explicitly.
The same class of bug appears in writable nested serializers. If a LineItem serializer accepts a nested order object with an id field, a user can point that id at any order. Validate every inbound relation. For more on how this nesting problem scales, the same concepts appear in authorization patterns in GraphQL APIs, where every resolver is effectively a relation that needs its own ownership check.
Test for IDOR with Automated Authorization Checks
The only reliable way to prevent IDOR regressions is to write tests that explicitly attempt cross-user access and assert they fail. Code reviews miss it. Manual QA misses it. Tests that authenticate as user B and try to touch user A’s resources catch it every time — if you write them.
# tests/test_order_idor.py
import pytest
from django.contrib.auth import get_user_model
from rest_framework.test import APIClient
from orders.models import Order
User = get_user_model()
@pytest.fixture
def alice(db):
return User.objects.create_user(username="alice", password="testpass123") # noqa: S106
@pytest.fixture
def bob(db):
return User.objects.create_user(username="bob", password="testpass123") # noqa: S106
@pytest.fixture
def alice_order(alice):
return Order.objects.create(owner=alice, total="99.99")
@pytest.mark.django_db
class TestOrderIDOR:
def _client_for(self, user):
client = APIClient()
client.force_authenticate(user=user)
return client
def test_bob_cannot_retrieve_alice_order(self, alice_order, bob):
# 404, not 403 — we don't confirm the resource exists to unauthorized users.
response = self._client_for(bob).get(f"/api/orders/{alice_order.id}/")
assert response.status_code == 404
def test_bob_cannot_update_alice_order(self, alice_order, bob):
response = self._client_for(bob).patch(
f"/api/orders/{alice_order.id}/", {"total": "0.01"}, format="json"
)
assert response.status_code == 404
def test_bob_cannot_delete_alice_order(self, alice_order, bob):
response = self._client_for(bob).delete(f"/api/orders/{alice_order.id}/")
assert response.status_code == 404
def test_bob_list_does_not_include_alice_order(self, alice_order, bob):
# List endpoint must not leak cross-user data even if IDs are unknown.
response = self._client_for(bob).get("/api/orders/")
assert response.status_code == 200
ids = [item["id"] for item in response.data["results"]]
assert str(alice_order.id) not in ids
The list-endpoint test is easy to forget and catches a different bug: get_queryset() returning everything on list() but correctly filtering on retrieve(). Write both.
Wire these into CI as required checks. A failing IDOR test should block a merge the same way a failing unit test does. This is not optional — the whole point is that a developer adding a new ModelViewSet in a Friday pull request doesn’t ship a data leak to production by Monday.
Catch IDOR in Code Review and CI
Human review of pull requests should pattern-match on a short list of high-risk constructs. Any Model.objects.get(pk=...) or Model.objects.filter(id=...) call that doesn’t chain a user-scoping filter is a candidate IDOR. Any ViewSet missing permission_classes is an unauthenticated endpoint or is inheriting from a base class that may not have adequate defaults. Any serializer field of type PrimaryKeyRelatedField with a broad queryset is a potential cross-tenant write.
Automate this with Semgrep. Here is a rule that flags the most common pattern: a DRF view calling .objects.get() without an owner filter anywhere in the same expression:
# semgrep/rules/drf-idor.yml
rules:
- id: drf-unscoped-objects-get
patterns:
- pattern: $MODEL.objects.get(pk=...)
- pattern-not: $MODEL.objects.get(pk=..., owner=...)
- pattern-not: $MODEL.objects.get(pk=..., owner__in=...)
message: >
Unscoped .objects.get(pk=...) in a view — add an owner filter or replace with
a queryset scoped in get_queryset(). Risk: IDOR.
languages: [python]
severity: ERROR
metadata:
cwe: CWE-639
Run this rule in your CI pipeline on every pull request. To shift IDOR checks left in your CI/CD pipeline, add it as a required status check alongside your test suite — not a separate “security scan” that developers learn to ignore.
Code review checklist for IDOR-prone patterns:
-
ModelViewSet or GenericAPIView subclass with no explicit get_queryset override — check what the default queryset returns.
-
permission_classes = [] or a ViewSet that inherits permission_classes from a base class you don’t control.
-
PrimaryKeyRelatedField(queryset=Model.objects.all()) in any writable serializer — this gives any user access to the full table.
-
perform_create or perform_update that doesn’t pin the owner field, leaving it open to user-supplied values.
- Tests that only assert
status_code == 200 for the happy path, with no cross-user negative test.
SAST tools like Semgrep will catch structural patterns; they won’t catch logic bugs where the filter is present but uses the wrong field. Code review has to cover that gap. The combination — automated rules catching the obvious omissions, human review focused on logic — is more effective than either alone.
Hardening Checklist and Next Steps
The layered controls, in priority order:
Queryset scoping (required): get_queryset() filters by request.user. No exceptions for convenience. If an admin view needs to return all objects, it lives in a separate ViewSet with explicit admin permission checks.
Object-level permissions (required): IsOwner or equivalent BasePermission with has_object_permission as a second line of defense. Attach it to every mutating ViewSet.
Serializer-level FK validation (required for relational writes): Every PrimaryKeyRelatedField or nested writable serializer validates that the referenced object belongs to request.user.
perform_create owner binding (required): Never accept owner from request data. Always call serializer.save(owner=self.request.user).
Opaque identifiers (defense in depth): UUIDs or opaque public IDs in all URLs and serializer output. Still mandatory to have the above controls in place.
Automated cross-user tests (required for CI gates): One test class per resource that authenticates as User B and asserts 404 on User A’s list, retrieve, update, and delete endpoints.
SAST rules in CI (defense in depth): Semgrep rules flagging unscoped .objects.get() and missing permission_classes, run as required checks on pull requests.
These controls address the majority of IDOR patterns in DRF, but authorization bugs extend well beyond the patterns covered here. If you want to build systematic habits around authorization review — across frameworks, auth protocols, and API types — the Application Security Engineer learning path on Code Review Lab covers the full scope, including scenarios more complex than single-tenant ownership checks.
The part most teams skip is the test suite. You can write perfect queryset scoping today and watch a future contributor add a get_object_or_404(Order, pk=pk) shortcut that bypasses it entirely. Tests that authenticate as the wrong user and assert 404 are the only automated check that catches that regression. Write them now, gate CI on them, and review them alongside any new ViewSet. If you want a reference for how IDOR shows up in security interviews and assessments, common IDOR interview questions are a useful signal for the gaps engineers typically leave in production systems.
Further Reading
-
OWASP IDOR Prevention Cheat Sheet — authoritative guidance on access control patterns across frameworks.
-
CWE-639: Authorization Bypass Through User-Controlled Key — the formal taxonomy entry with real-world consequences and detection guidance.
-
Django REST Framework: Permissions — official DRF docs on
has_permission and has_object_permission, including check_object_permissions call semantics.
-
Application Security Engineer learning path on Code Review Lab — structured curriculum for building authorization review skills across multiple API paradigms.
-
PortSwigger Web Security Academy: IDOR — interactive labs that demonstrate enumeration, parameter tampering, and horizontal privilege escalation in concrete exercises.
