What do security teams get wrong about authentication and authorization in Django REST Framework?

Authentication is not the whole control in DRF

In Django REST Framework, authentication answers a narrow question, who is making the request. That is useful, but it is not the access decision. Once DRF has identified the caller, the view still needs an authorization decision, usually through permission classes, to decide whether that caller may reach the endpoint or perform the action.

This is where teams often overfit the sign-in layer and underbuild the policy layer. A request can be successfully authenticated and still be entirely inappropriate for the route, object, or action that follows. In practice, that means a well-formed identity can still reach data or functions that were meant to stay restricted if permissions are absent, too broad, or only applied inconsistently.

DRF makes this separation deliberate. Authentication establishes identity context, while permissions enforce the rule set that governs that context. If you collapse those into one mental model, you end up treating “logged in” as equivalent to “allowed,” which is the most common design error behind accidental exposure in API endpoints.

How the split shows up in real DRF designs

The practical distinction is simple: authentication validates the caller, permissions authorise the request. That means the default question for a security review is not “does this endpoint authenticate?” but “what does this endpoint allow after authentication succeeds?” The difference matters most when a view should be available only to staff, only to owners, or only to specific roles or scopes.

This separation also affects how you read permission logic in code. A global authentication setting does not secure a view by itself, and a token or session proving identity does not imply the request should pass. If the permission class is permissive, missing, or overridden lower in the stack, the endpoint may still be reachable by authenticated but unauthorised callers.

That is why authorization should be reviewed at the same time as route design, serializer exposure, and object-level checks. Endpoint access is not just about whether someone has an account, but whether the authenticated principal should be able to list, retrieve, create, update, or delete the specific resource in front of them.

What security teams should verify before they trust a DRF endpoint

Security reviews should start with the permission boundary, not the login mechanism. A useful check is to confirm that every endpoint has an explicit access rule, that the rule matches the business need, and that object-level restrictions are not assumed when only view-level checks exist. The goal is to make the authorisation decision visible, testable, and repeatable.

• Confirm the endpoint does not rely on authentication alone for protection.
• Check that the permission class matches the intended audience for the view.
• Verify object-level access is enforced where records are user-specific or tenant-specific.
• Test both authenticated success and authenticated-but-denied paths.

For API-centric authorization patterns, the OWASP API Security Top 10 is a useful external lens because broken authorisation is a common failure mode in service endpoints. For a more concrete control model around access decisions, NHIMG’s Authorisation Models Guide helps teams think beyond “is the user logged in?” toward “is this identity allowed to do this action on this resource?”

Practitioner Guidance

What to prioritise: Treat permission design as a first-class control, not a follow-on detail. If the endpoint handles sensitive records, administrative actions, or tenant-scoped data, the authorization rule should be explicit in the view contract and verified in tests, not inferred from middleware or defaults.

What to verify: Review the negative case, not just the happy path. Security teams should confirm that an authenticated caller who should not have access receives a denial for each protected action, and that the denial still holds when the caller is authenticated through a different mechanism or role than the one originally tested.

Common mistake: Teams often pass a sign-in test and stop there. That creates a false sense of control because authentication proves only who the caller is, not whether they are entitled to the endpoint, the object, or the operation.

Practitioner takeaway: In DRF, the security question is never “is the caller authenticated?” by itself, but “what policy decides whether this authenticated caller may do this thing?”

Related resources from NHI Mgmt Group

• Guide: IAM and IGA Basics
• What do security teams get wrong about passwordless authentication and AI risk?
• What do security teams get wrong about passwordless authentication?
• What do security teams get wrong about passwordless authentication in regulated environments?
• What do security teams get wrong about LLM-generated authentication code?