Review Django Access Control and IDOR Vulnerabilities

Django Access Control & IDOR Review provides an investigation-driven method for reviewing authorization in Django and Django REST Framework code. Its central question is whether User A can read, change, or delete User B's data. Instead of matching a list of suspicious patterns, it asks the reviewer to understand the specific codebase, trace how resource identifiers reach data access, and report only confirmed gaps.

The process starts by learning where authorization is enforced: decorators, middleware, base views, DRF permission classes, mixins, querysets, or custom managers. It identifies whether resources belong to a user, organization, tenant, or hierarchy and whether roles affect access. It then maps user-data models, ownership fields, endpoints, and exposed operations such as list, retrieve, create, update, delete, bulk actions, and custom actions.

Use this skill when reviewing Django or DRF views, viewsets, ORM queries, or Python code that handles user authorization. It is suited to investigating access control gaps, insecure direct object reference risk, and object-level permission failures. It also helps check tenant isolation and whether related records follow the same access boundaries as their parent resource.

Do not treat a suspicious pattern as a finding on its own. A broad queryset or direct lookup is an indicator to investigate, not proof of a vulnerability: a base class, manager, middleware, decorator, or object permission may enforce the missing-looking control. The skill is not a substitute for examining the actual application and its authorization model.

Inputs are a Django or DRF codebase, the endpoints and models that handle sensitive data, and the relevant ownership or tenant model. For a concrete flow, trace where an ID comes from (URL, query parameter, or request body), where it is used in an ORM or database call, and what checks occur between those points. Review list queries for user scoping, create flows for server-side ownership assignment, bulk operations for scoping, related objects for inherited access, and tenant identifiers for cross-organization access.

The result is an evidence-based report with an authorization model summary, confirmed findings, items needing manual verification, and areas not reviewed. Findings should name the component, confidence, question investigated, trace steps, evidence, impact, and an enforcing code fix. The source distinguishes high confidence (the flow is traced and no check exists), medium (a check may exist but could not be confirmed), and low (theoretical and likely mitigated); low-confidence issues should not be reported as vulnerabilities.

A confirmed issue should explain why an authenticated user can reach another user's record, including queryset behavior and object checks. Suggested fixes must enforce access, for example by scoping a query or checking ownership and rejecting unauthorized requests. Documentation that tells callers to check permissions is not enforcement.

The review covers Django decorators such as login and permission requirements, middleware, base classes, DRF permission classes and has_object_permission(), custom mixins, custom managers, get_queryset() overrides, and ORM queries. It considers user and organization filters, server-side ownership assignment during create operations, and explicit permission checks. The included investigation examples use repository search commands to find permission declarations, view base classes, queryset methods, and ownership fields.

Potential warning signs include an unscoped .all(), a direct lookup without ownership in the query, a client-controlled ID, an authentication-only permission, or absent object permissions when the queryset is not scoped. Each must be checked against parent classes, middleware, managers, decorators, and the application's actual behavior before drawing a conclusion.

Django and DRF developers, security reviewers, and application maintainers can use this method to make access-control reviews specific and reproducible. It is especially relevant to systems with user-owned or tenant-owned records, where a reviewer needs to verify who can retrieve, update, delete, or associate each resource.