DEFAULT_PERMISSION_CLASSES and per-view permission_classes override boundary

Answer to the Core Question

In Django REST Framework 3.x the following rules apply:

• Omitted permission_classes attribute – the view inherits the list from settings.REST_FRAMEWORK['DEFAULT_PERMISSION_CLASSES'].
• Explicit permission_classes = [] – the view disables all permission checks, effectively behaving as AllowAny regardless of the global default.
• When DEFAULT_PERMISSION_CLASSES is changed, every view that has not overridden permission_classes will see the new default. Views that have already overridden it (even with an empty list) are unaffected.

When a View Without permission_classes Remains Public

After you modify DEFAULT_PERMISSION_CLASSES, a view that originally had no permission_classes will stay publicly accessible only if:

• The global default itself is AllowAny, or
• Some ancestor class or mixin has set permission_classes = [], which the view inherits.

Otherwise, the view will enforce the new default (e.g., IsAuthenticated will block unauthenticated requests).

Authoritative Boundary for Permission Inheritance

The documentation treats the global setting as the source of truth unless a view explicitly overrides it. In practice the inheritance chain is:

1. View class defines permission_classes → use that list.
2. View inherits from a base class that defines permission_classes → use that list.
3. Otherwise → use settings.REST_FRAMEWORK['DEFAULT_PERMISSION_CLASSES'].

Practical Verification Steps

1. Open settings.py and confirm the current value of REST_FRAMEWORK['DEFAULT_PERMISSION_CLASSES'].
2. Search your codebase for any class that sets permission_classes = [] (including mixins and custom base views).
3. For a view that has no permission_classes defined, send an unauthenticated request and check the status code:
   • 200‑299 → the view is effectively AllowAny.
   • 401/403 → the view is enforcing the global default.
4. Temporarily change DEFAULT_PERMISSION_CLASSES to ['rest_framework.permissions.AllowAny'] and repeat the unauthenticated request. If the status code remains 200‑299, the view is still unrestricted; if it changes to 401/403, the view was previously inheriting a stricter default.
5. If any view is unexpectedly public, trace its inheritance chain to locate an ancestor that sets permission_classes = [] and add an explicit override (e.g., permission_classes = [IsAuthenticated]) to secure it.

Missing Diagnostic Detail Needed

To give a more precise recommendation, could you share:

1. The current value of REST_FRAMEWORK['DEFAULT_PERMISSION_CLASSES'] in your settings.
2. Whether any custom base view or mixin in your project sets permission_classes = [].

These details will confirm if any of your views are unintentionally inheriting an empty permission list.