What is the difference between Django’s CSRF middleware and the csrf_exempt decorator?

Why the distinction matters in Django security

csrf protection in Django is a request-validation control, not a general access-control mechanism. The middleware applies that protection consistently across the application, while csrf_exempt creates a deliberate exception for a single view. That difference matters because one is the default safety net and the other is a narrowly scoped override that can reopen cross-site request paths if it is used too broadly or without a compensating control.

For teams reviewing web application security, the practical question is not whether the decorator “turns off CSRF” in the abstract, but whether the endpoint still has a trustworthy alternative boundary, such as a signed webhook, a separate authentication scheme, or a read-only operation that cannot change state. If the view accepts side-effecting requests from browsers, exemption changes the threat model immediately. In practice, many CSRF issues surface when a one-off exemption added for integration convenience quietly becomes a permanent exception path.

How it works in practice

Django’s CSRF middleware checks that state-changing requests carry a valid token tied to the user’s session or request context. In normal browser flows, the token is embedded in forms or sent in headers by client-side code, and the middleware rejects requests that fail the match. This gives you broad, default enforcement without requiring each individual view to implement its own check.

csrf_exempt changes only one thing: Django skips CSRF validation for the decorated view. The request may still be authenticated, authorised, logged, rate-limited or otherwise protected, but it is no longer protected by Django’s built-in CSRF check. That makes the decorator useful for endpoints that do not fit browser token workflows, especially machine-to-machine callbacks or third-party webhooks, provided the endpoint has its own integrity and authenticity controls.

In practice, teams should treat exemption as an architectural decision rather than a convenience flag. The important implementation questions are:

• Does the endpoint mutate server state?
• Can the caller prove authenticity in some other way?
• Is the endpoint reachable from a browser context?
• Would the same action be safe if triggered cross-site?

If the answer to the first and fourth questions is yes, the exemption needs a stronger justification than “the integration was hard to wire up.” These controls tend to break down when a browser-facing POST endpoint is exempted to accommodate a legacy client and the exception is never revisited.

Common variations and edge cases

Tighter CSRF enforcement often increases integration overhead, so teams have to balance developer convenience against the cost of keeping a safe request boundary. The standard pattern works well for conventional form submissions, but some legitimate workflows need a different trust model.

Webhook receivers are the most common edge case: they often need csrf_exempt because the caller is not a browser and cannot attach a Django CSRF token. In those cases, the security decision shifts to signature verification, shared secrets, replay protection, source allowlisting, or another authenticity check. By contrast, API endpoints consumed by browser-based single-page applications often do better with token-based CSRF handling rather than exemption.

Another common mistake is confusing CSRF with authentication. A request can be authenticated and still be vulnerable to CSRF if the browser automatically sends credentials. Exemption therefore has real consequences even when the view is behind login, because the attack path is about abusing an already-signed-in browser session. Current guidance suggests using exemption only when the endpoint’s trust model genuinely differs from the rest of the application.

Practitioner Guidance

What to prioritise: Start by classifying the endpoint by trust model, not by implementation convenience. If the view changes state and is reachable from a browser, preserve CSRF protection unless there is a clearly documented alternative control that proves request authenticity.

Decision rule: If you must use csrf_exempt, require a compensating control that is stronger than obscurity, such as cryptographic request signing or a verified callback mechanism. If you cannot point to that control in the review record, treat the exemption as a security defect, not a harmless refactor.

What to verify: Confirm that exempted views are intentionally narrow, version-controlled, and easy to inventory. Review them for state change, login context, browser reachability, and the presence of a non-CSRF authenticity check before approving deployment.

Practitioner takeaway: The key judgement is whether the endpoint still has a defensible trust boundary after CSRF validation is removed. If it does not, the decorator has turned a framework safeguard into an avoidable exposure.

Related resources from NHI Mgmt Group

• What is the difference between CORS and CSRF protection in Django applications?
• What is the difference between CSRF protection and CORS hardening in this context?
• What is the difference between session-based auth and token-based API auth in Django?
• What is the difference between middleware-based auth and scattered route checks?