Global DEFAULT_PERMISSION_CLASSES versus Per‑View Permission Classes for Securing Mixed Public‑Read/Admin‑Write Endpoints

When building a Django REST API that exposes a public‑read‑only list endpoint while restricting create, update, and delete actions to admin users, developers must decide where to enforce authentication.

One approach relies on a global DEFAULT_PERMISSION_CLASSES setting (e.g., IsAuthenticated) and then overrides specific views with AllowAny for the list method. The alternative leaves the global setting unset (default AllowAny) and applies IsAdminUser (or a custom permission) only to the mutating methods.

Both strategies aim to achieve the same security posture, but they differ in how permission inheritance interacts with viewsets, routers, and method‑level overrides, which can produce unexpected effective permissions if a view is missed or a third‑party package adds a view.

What are the practical trade‑offs between setting a restrictive global default and relying on per‑view overrides, and how can teams verify that no endpoint is unintentionally left open?