Insecure Direct Object Reference in Django with Cockroachdb

An Insecure Direct Object Reference (IDOR) occurs when an API exposes a reference to an internal implementation object—such as a database primary key—in a predictable way and lacks sufficient authorization checks before returning or modifying that object. In Django applications using CockroachDB, IDOR commonly appears in URL designs like /api/invoices/123/ where 123 is a CockroachDB-stored primary key (e.g., BIGINT or UUID). Because CockroachDB implements a PostgreSQL wire protocol and SQL dialect, Django’s ORM generates queries such as SELECT * FROM invoice WHERE id = %s and streams results back to the application. If the view does not enforce tenant or ownership checks, an attacker can iterate through numeric or UUID identifiers and read or modify records belonging to other users.

Django’s default permission model does not automatically enforce object-level restrictions; it focuses on model-level permissions. CockroachDB’s strong consistency and distributed SQL nature do not mitigate this risk. An attacker leveraging an exposed, predictable primary key can use simple GET requests to enumerate sensitive data (e.g., user profiles, transaction records) or perform unauthorized actions like changing an invoice status or transferring funds. When combined with complementary flaws such as missing rate limiting or verbose error messages that reveal stack traces or SQL hints, IDOR becomes easier to weaponize. Tools like middleBrick can detect IDOR patterns by correlating OpenAPI/Swagger definitions (including $ref resolutions across schemas) with runtime behavior, including how endpoints reference Cockroachdb-backed models without proper row-level security checks.

For example, a view that retrieves a Document by ID without verifying the requesting user’s relationship to that document creates a direct IDOR vector:

def document_detail(request, document_id: int):
    doc = Document.objects.get(id=document_id)  # No ownership check
    return JsonResponse({'name': doc.name, 'content': doc.content})

In this snippet, document_id maps directly to a Cockroachdb table primary key. An authenticated user can modify the numeric parameter to access another user’s document. Because CockroachDB handles distributed transactions and indexes efficiently, the query will succeed and return data, but the application layer fails to enforce authorization, resulting in a high-risk finding in categories like BOLA/IDOR and Property Authorization that middleBrick reports with severity and remediation guidance.

To remediate IDOR when using CockroachDB with Django, enforce object-level authorization in every view or serializer that references a row by primary key. Always scope queries to the requesting user or tenant. Below are concrete, working examples that demonstrate safe patterns.

1. Scoped Query with Explicit Ownership

Ensure the query filters by both the object ID and the requesting user (or tenant). This prevents direct object references from being used in isolation.

from django.shortcuts import get_object_or_404
from django.http import JsonResponse
from .models import Invoice

def invoice_detail(request, invoice_id: int):
    # Safe: scope to the requesting user's invoices in Cockroachdb
    invoice = get_object_or_404(Invoice, id=invoice_id, user=request.user)
    return JsonResponse({'invoice_id': invoice.id, 'amount': invoice.amount})

2. UUID-based Keys with Tenant Isolation

When using UUID primary keys (recommended for distributed CockroachDB deployments), validate tenant or ownership fields in the filter. CockroachDB stores UUIDs natively, and Django can handle them with models.UUIDField.

import uuid
from django.http import JsonResponse
from .models import Report

def report_detail(request, report_id: str):
    report_uuid = uuid.UUID(report_id)
    report = get_object_or_404(Report, id=report_uuid, tenant=request.tenant)
    return JsonResponse({'report_id': str(report.id), 'title': report.title})

3. Using Django REST Framework with ViewSets and Permissions

In DRF, implement object-level permissions and use perform_object_permissions or a custom permission class. Filter the queryset by the requesting user’s tenant or relationship.

from rest_framework import viewsets, permissions
from .models import Project
from .serializers import ProjectSerializer

class ProjectViewSet(viewsets.ReadOnlyModelViewSet):
    serializer_class = ProjectSerializer

    def get_queryset(self):
        # Scope to the requesting user's projects in Cockroachdb
        return Project.objects.filter(owner=self.request.user)

    def get_permissions(self):
        if self.action in ['retrieve', 'list']:
            return [permissions.IsAuthenticated(), self.object_level_permission]
        return super().get_permissions()

    def perform_object_permissions(self, instance):
        if instance.owner != self.request.user:
            self.permission_denied(self.request)

4. Row-Level Security via Database Policies (Optional Advanced Pattern)

Although Django does not enforce RLS, you can define database-side policies in CockroachDB and ensure queries respect them by scoping in the application. This adds defense-in-depth.

-- CockroachDB SQL policy example (run separately)
CREATE POLICY user_invoice_policy ON invoices
FOR SELECT USING (user_id = auth.uid());

In Django, continue to scope queries as shown earlier; the policy ensures that even if a bug bypasses application checks, CockroachDB will reject unauthorized reads at the storage layer.

5. Validate and Normalize Input

Always validate the type and format of object identifiers. Use Django path converters and serializer fields to avoid malformed IDs reaching the database layer.

from rest_framework import serializers

class InvoiceSerializer(serializers.ModelSerializer):
    class Meta:
        model = Invoice
        fields = ['id', 'amount', 'status']
        read_only_fields = ['id']

    def to_internal_value(self, data):
        # Ensure id is a valid integer or UUID before querying
        return super().to_internal_value(data)