Review Django Access Control and IDOR Vulnerabilities

Investigates a Django or DRF codebase for access-control and IDOR (Insecure Direct Object Reference) vulnerabilities by answering one concrete question: can User A access, modify, or delete User B's data? Instead of scanning for predefined vulnerable patterns, it works in five phases. First, understand this specific codebase's authorization model - where permission checks live (decorators, middleware, base classes, DRF permission classes, custom mixins), how queries are scoped (custom managers, get_queryset() overrides), and the ownership model (single-user, organization/tenant, hierarchical, or role-based) - using grep-based investigation commands to find permission_classes, @login_required/@permission_required, base/mixin classes, custom managers, and ownership fields on models. Second, map the attack surface: which models hold user data, which have ownership fields, and which are reached via an ID in a URL or request body, across list/detail/create/update/delete/custom-action endpoints. Third, for each endpoint, trace where a resource ID enters the system, where that ID is used to fetch data, and what checks exist in between - checking parent classes, middleware, managers, and decorators if none are found. Fourth, walk one concrete flow end to end, e.g. tracing GET /api/documents/{pk}/ through DocumentViewSet.retrieve(), its permission_classes, its get_queryset(), and any has_object_permission(), to reach an evidence-backed conclusion. Fifth, report only what investigation confirmed, tagged HIGH (traced and confirmed no check exists), MEDIUM (a check may exist but couldn't be confirmed, flagged for manual verification), or LOW (theoretical and likely mitigated, not reported).

Use it when reviewing Django views, DRF viewsets, ORM queries, or any Python/Django code that handles user authorization, especially when the task is confirming whether one user can reach another user's data, or when you want an investigation-driven review rather than generic pattern matching against a fixed vulnerability list. It is not a checklist-matching scanner: patterns like get_queryset() returning .all(), a bare Model.objects.get(pk=pk) with no ownership filter, or a permission class that checks only authentication (not ownership) are gap indicators to investigate further, never auto-flags. Suggested fixes must enforce authorization in code, not just document an expectation in a comment - a docstring telling callers "you must check permissions" is treated as a non-fix.

def get_resource(resource_id, user):
    resource = Resource.objects.get(pk=resource_id)
    if resource.owner_id != user.id:
        raise PermissionDenied("Access denied")
    return resource

Input is the Django/DRF codebase under review. Output is a Markdown report per component: an authorization-model summary, a findings list where each item (IDOR-NNN) states severity, file:line location, confidence level, the core question asked, the investigation steps taken, code evidence, impact, and a suggested fix that is itself enforcing code like the example above rather than a comment - plus a "Needs Manual Verification" section for unconfirmed checks and an "Areas Not Reviewed" section listing what was out of scope for the pass.

Works directly against a Django/DRF codebase via shell investigation (grep for permission_classes, base/mixin classes, custom managers, and ownership fields in models.py) rather than any external service; its report format and OWASP-derived reference material (Cheat Sheet Series, CC BY-SA 4.0) are self-contained.

Security reviewers and backend engineers auditing Django/DRF applications for IDOR and object-level authorization gaps who want evidence-based findings with confidence ratings and enforceable fixes, not a generic pattern-matching scan.