Broken Access Control in Django

Broken Access Control in Django applications often stems from improper use of Django's authentication and authorization systems. The most common manifestation is developers bypassing Django's built-in permission checks or incorrectly implementing custom permission logic. A typical scenario involves using request.user without verifying authentication status, or relying on client-side data for authorization decisions.

Consider a Django view that allows users to view and edit their profiles:

from django.shortcuts import get_object_or_404, render
from django.contrib.auth.decorators import login_required
from .models import UserProfile

@login_required
def edit_profile(request, user_id):
    profile = get_object_or_404(UserProfile, id=user_id)
    if request.method == 'POST':
        # BUG: No check that user owns this profile
        profile.bio = request.POST['bio']
        profile.save()
    return render(request, 'profile_edit.html', {'profile': profile})

This code appears secure because of the @login_required decorator, but it contains a critical flaw. Any authenticated user can edit any profile by simply changing the user_id parameter. This is a classic IDOR (Insecure Direct Object Reference) vulnerability specific to Django's URL parameter handling.

Another Django-specific pattern involves ModelAdmin configurations where developers forget to set list_display or list_editable permissions:

from django.contrib import admin
from .models import UserAccount

@admin.register(UserAccount)
class UserAccountAdmin(admin.ModelAdmin):
    list_display = ('id', 'username', 'email', 'balance')
    list_editable = ('balance',)  # DANGEROUS: allows anyone with admin access to edit balances

Even with proper authentication, this allows any admin user to modify account balances without proper authorization checks. Django's admin interface doesn't automatically enforce row-level permissions unless explicitly configured with third-party packages like django-guardian.

Property authorization bugs also appear in Django through serializer fields in DRF (Django REST Framework) views:

from rest_framework import serializers
from .models import Document

class DocumentSerializer(serializers.ModelSerializer):
    class Meta:
        model = Document
        fields = ('id', 'title', 'content', 'owner', 'is_public')
        read_only_fields = ('owner',)  # BUG: owner is read-only but not properly checked in update

def document_detail(request, pk):
    doc = get_object_or_404(Document, pk=pk)
    serializer = DocumentSerializer(doc)
    return Response(serializer.data)

Without checking request.user == doc.owner, any authenticated user can access any document's content, regardless of ownership.

Detecting Broken Access Control in Django requires examining both the code structure and runtime behavior. Static analysis can identify common patterns like missing permission checks, but runtime scanning with tools like middleBrick provides comprehensive coverage of the actual attack surface.

middleBrick's Django-specific detection focuses on the unauthenticated attack surface, testing endpoints without requiring credentials. For Django applications, this means scanning public URLs and examining how the framework handles unauthorized access attempts. The scanner tests for common Django authentication bypass patterns, including:

• Missing or improperly configured @login_required decorators on views
• Admin interface endpoints accessible without proper permissions
• CSRF token handling failures that could enable authenticated request forgery
• Session fixation vulnerabilities in Django's session management
• URL parameter manipulation that bypasses object ownership checks
• DRF serializer field exposure that reveals sensitive data

When scanning a Django application, middleBrick examines the HTTP responses for telltale signs of broken access control. For instance, Django typically returns a 302 redirect to the login page when unauthenticated users access protected views. However, if an endpoint returns a 200 status code with sensitive data or allows data modification without proper authentication, this indicates a serious vulnerability.

The scanner also tests Django's middleware stack by attempting requests that should be blocked by various security middleware. This includes testing for clickjacking protection bypass, cross-site scripting through template rendering, and session security misconfigurations.

For Django applications using REST Framework, middleBrick specifically tests the permission classes and authentication classes defined in the API views. It attempts to access endpoints with various authentication headers and examines whether the framework properly enforces the declared permissions.

middleBrick's Property Authorization check is particularly relevant for Django applications, as it examines whether model fields that should be protected (like user, owner, or balance) are properly secured in both the model layer and the view/serializer layer.

Remediating Broken Access Control in Django requires leveraging the framework's robust authentication and authorization systems correctly. The first principle is to never trust client-side data for authorization decisions. Instead, always verify the authenticated user's permissions against the requested resource.

For the profile editing example, the fix involves adding explicit ownership verification:

from django.shortcuts import get_object_or_404, render
from django.contrib.auth.decorators import login_required
from django.core.exceptions import PermissionDenied
from .models import UserProfile

@login_required
def edit_profile(request, user_id):
    profile = get_object_or_404(UserProfile, id=user_id)
    
    # CRITICAL: Verify user owns this profile
    if profile.user != request.user:
        raise PermissionDenied
    
    if request.method == 'POST':
        profile.bio = request.POST['bio']
        profile.save()
    return render(request, 'profile_edit.html', {'profile': profile})

Django provides several mechanisms for implementing proper access control. The django.contrib.auth decorators like @login_required, @user_passes_test, and @permission_required should be used consistently across all views that handle sensitive data.

For more granular control, Django's permission system allows defining custom permissions on models:

from django.db import models
from django.contrib.auth.models import User

class Document(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    owner = models.ForeignKey(User, on_delete=models.CASCADE)
    
    class Meta:
        permissions = (
            ('view_document', 'Can view document'),
            ('edit_document', 'Can edit document'),
        )

Then enforce these permissions in views:

from django.contrib.auth.decorators import permission_required

@permission_required('app.view_document', raise_exception=True)
def document_detail(request, pk):
    doc = get_object_or_404(Document, pk=pk)
    if doc.owner != request.user:
        raise PermissionDenied
    return render(request, 'document_detail.html', {'document': doc})

For Django REST Framework applications, use the built-in permission classes:

from rest_framework import viewsets, permissions
from .models import Document
from .serializers import DocumentSerializer

class DocumentViewSet(viewsets.ModelViewSet):
    queryset = Document.objects.all()
    serializer_class = DocumentSerializer
    
    # Enforce ownership-based permissions
    permission_classes = [
        permissions.IsAuthenticated,
        permissions.BasePermission,
    ]
    
    def get_permissions(self):
        if self.action in ['update', 'partial_update', 'destroy']:
            return [permissions.IsAuthenticated(), IsOwner()]
        return [permissions.IsAuthenticated()]

class IsOwner(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        return obj.owner == request.user

For admin interface security, use the django-guardian package for row-level permissions:

from guardian.shortcuts import get_objects_for_user

@admin.register(UserAccount)
class UserAccountAdmin(admin.ModelAdmin):
    list_display = ('id', 'username', 'email', 'balance')
    
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        # Only show accounts the user has permission to view
        return get_objects_for_user(request.user, 'view_account', qs)

Always test your access control implementation thoroughly. Use Django's test client to simulate requests from different user types and verify that permissions are enforced correctly at every level of your application stack.