DRF Permissions

Permissions answer “is this request allowed to do this?” after authentication has answered “who is this?”. They run after authentication_classes and before the view method.

Built-in permission classes

Default project-wide permission

# settings.py
REST_FRAMEWORK = {
    "DEFAULT_PERMISSION_CLASSES": [
        "rest_framework.permissions.IsAuthenticated",
    ],
}

Always set this explicitly. The DRF default is AllowAny — easy to ship a public-by-default API.

Per-view permissions

class BookViewSet(viewsets.ModelViewSet):
    permission_classes = [IsAuthenticated, IsBookOwner]

All listed classes must pass (logical AND). For OR / NOT logic use bitwise operators on instances:

# admin OR owner
permission_classes = [IsAdminUser | IsOwner]
permission_classes = [IsAuthenticated & ~IsBanned]

Per-action permissions

For ViewSets:

def get_permissions(self):
    if self.action in ("list", "retrieve"):
        return [permissions.AllowAny()]
    if self.action == "destroy":
        return [permissions.IsAdminUser()]
    return [permissions.IsAuthenticated()]

Note () — get_permissions returns instances, not classes.

Writing a custom permission

Two methods to optionally override:

from rest_framework.permissions import BasePermission, SAFE_METHODS

class IsOwnerOrReadOnly(BasePermission):
    def has_permission(self, request, view):
        # called BEFORE the view method runs, before get_object()
        return request.user.is_authenticated or request.method in SAFE_METHODS

    def has_object_permission(self, request, view, obj):
        # called by get_object() on detail endpoints
        if request.method in SAFE_METHODS:
            return True
        return obj.owner_id == request.user.id

Important: has_object_permission is only called from get_object(). If your view doesn’t call get_object() (e.g. a custom action that filters its own queryset), you must call self.check_object_permissions(request, obj) yourself.

SAFE_METHODS

# ("GET", "HEAD", "OPTIONS")
from rest_framework.permissions import SAFE_METHODS

Use it instead of hardcoding the tuple — it’s the canonical “read-only HTTP method” check.

Object-level vs view-level: when each runs

Common bug: people put their authorization logic in has_object_permission and assume it filters list endpoints too. It doesn’t. For list filtering, scope get_queryset():

def get_queryset(self):
    qs = super().get_queryset()
    if self.request.user.is_staff:
        return qs
    return qs.filter(owner=self.request.user)

Returning 401 vs 403

• 401 Unauthorized = not authenticated, but the endpoint requires auth. DRF returns this when request.user is AnonymousUser and a permission requires auth.
• 403 Forbidden = authenticated but not allowed.

DRF picks between them based on whether any authentication_classes returned a WWW-Authenticate header. If yes, anonymous = 401; otherwise = 403.

Throttling vs permissions

Both can deny a request, but:

• Permissions: identity-based (“admins only”).
• Throttling: rate-based (“max 100/hour”). See DRF Throttling.

Common patterns

Read-only public, write authenticated (the most common API)

permission_classes = [IsAuthenticatedOrReadOnly]

Owner-only edits

permission_classes = [IsAuthenticated, IsOwnerOrReadOnly]

Tenant scoping at the queryset level (defense in depth)

def get_queryset(self):
    return super().get_queryset().filter(tenant=self.request.user.tenant)

Permissions check intent; querysets ensure the data the user could try to access is already filtered. Both together prevent enumeration leaks.