Authorization in Django: From Permissions to Policies — Part 13 (Capstone) — Authorization Is Not Security
On Boundaries, Guarantees, and the Limits of Authorization
By this point in the series, authorization should no longer feel like a feature.
It should feel like a boundary.
— Permissions define who may attempt an action.
— Policies define what is valid now.
— Invariants define what must never be false.
Together, they form a perfectly designed authorization system. Even then, security is not guaranteed, because allowing the right actions does not prevent failure under misuse, concurrency, or error.
That distinction matters more than most teams realize.
The Category Error That Causes Incidents
When production incidents are analyzed, authorization failures are often described using security language:
“An access control issue.”
“A permissions bug.”
“An authorization bypass.”
Most of these incidents are not the result of attackers defeating a secure system.
They come from systems that were never designed to defend against misuse.
Authorization answers a narrow question:
Should this action be allowed?Security answers a broader one:
What happens when the system is stressed, misused, partially failed, or actively abused?
When these questions are conflated, teams expect authorization to provide guarantees it was never meant to provide.
How Authorization Failures Become Security Incidents
Most real-world data leaks do not begin with sophisticated exploits. They begin with ordinary assumptions that slowly become unsafe.
A permission check passes, but the object has changed since it was fetched.
A policy allows an action, but two requests race each other.
An invariant is assumed, but never enforced at the persistence layer.
A background job bypasses checks “because it’s internal.”
None of these are malicious acts.
All of them are authorization blind spots.
From the system’s point of view, everything was allowed.
From reality’s point of view, something impossible just happened.
Security incidents often emerge not from broken authorization, but from asking authorization to do the work of system integrity.
Why Django Cannot—and Should Not—Solve Security
A recurring theme in this series is restraint.
Django permissions are static, explicit, and deliberately limited. They do not encode context, intent, or workflow. This is not an oversight. It is a design choice.
Django does not try to be a security framework. It provides stable primitives:
A consistent identity model
Deterministic permission checks
Clear integration points
Everything else—policies, invariants, concurrency control, auditability—belongs to application architecture.
This is not a weakness. It is a boundary.
Security cannot be added to authorization the way conditions are added to permissions. It must be expressed through system design: transaction boundaries, state machines, idempotency, isolation, observability, and failure handling.
Authorization participates in security. It is not the same thing.
The Silent Failures Are the Dangerous Ones
The most dangerous authorization failures are not the ones that raise errors.
They are the ones that succeed.
A delete operation runs twice.
A refund is processed after settlement.
A user is removed from a group while a long-running task still holds a reference.
A record is updated after it was finalized.
Nothing crashes.
No permission is violated.
No policy is tripped.
And yet the system is now lying.
Security incidents often begin as data-integrity failures that remain unnoticed until their consequences compound.
Authorization as a Long-Lived Contract
Throughout this series, authorization has been treated not as a decision point, but as a contract between layers of the system.
Permissions promise stable capability boundaries.
Policies promise contextual validity.
Invariants promise systemic truth.
Security emerges when those promises hold under stress, not just when code paths are followed.
This is why authorization design must be conservative, explicit, and unremarkable. Every shortcut introduces an assumption. Every assumption becomes a liability under load, concurrency, or change.
Systems that fail spectacularly rarely lack checks. They fail because the responsibilities of those checks were never clearly defined.
What This Series Was Really About
This was never a series about Django APIs. It was about learning to see authorization as architecture rather than logic—shifting from asking where a check belongs to asking which layer is responsible for a given truth. Django provides a clean foundation by refusing to answer questions it cannot guarantee. What you build on top of it determines whether your system merely works, or whether it holds.
A Final Boundary
Authorization decides what may happen.
Security decides what must not be possible.
When those lines blur, systems drift toward fragility.
When they are respected, systems gain resilience—even under failure.
That boundary is not a framework feature.
It is an architectural choice.
And it is one you now understand well enough to defend.
Bibliography / References
Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. MIT / IEEE.
https://web.mit.edu/Saltzer/www/publications/protection/Evans, Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Addison-Wesley.
https://martinfowler.com/books/eaa.htmlKleppmann, Martin (2017). Designing Data-Intensive Applications. O’Reilly Media.
Gray, Jim, & Reuter, Andreas (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann.
Django Software Foundation. Django Authentication and Authorization. Official Django Documentation.
https://docs.djangoproject.com/en/stable/topics/auth/
Companion Project
-- Companion Django Project --
Purpose
-------
This project accompanies the series “Authorization in Django: From Permissions to Policies”.
It is not a tutorial or a feature demo, but a small, readable system that makes the architecture tangible.
The goal is to show how authorization works as a contract:
from request, to decision, to state change—without collapsing responsibilities.
Scope
-----
The project is intentionally small.
One domain, one workflow, one way to mutate state.
Every part exists to demonstrate a boundary, not a feature.
Domain
------
A simple post-publishing workflow with four states:
- Draft
- In Review
- Published
- Archived
The workflow is linear and explicit. No hidden transitions.
Roles
-----
- Author (writes posts)
- Reviewer/Editor (approves publication)
- Staff/Admin (archives posts)
Roles exist only to make authorization decisions concrete.
Authorization Model
-------------------
The system separates three concerns:
1. Capability — who may attempt an action
2. Validity — whether the action is allowed now
3. Truth — what must never be allowed to exist
These concerns must never collapse into one.
Permissions (Capability)
------------------------
Permissions express what a user may attempt in principle.
They are static, simple, and context-free.
Permissions do not know state, ownership, or timing.
Policies (Validity)
-------------------
Policies decide whether an action is allowed now.
They may inspect state, relationships, and workflow position.
Policies never mutate data.
Invariants (Truth)
------------------
Invariants enforce conditions that must always hold.
They are checked at mutation time and do not trust callers or prior checks.
If an invariant would be violated, the operation must fail.
Workflow
--------
All state changes go through explicit workflow actions
(e.g., submit for review, publish, archive).
Each action follows the same sequence:
permission → policy → invariant-safe mutation.
No other code path may change post state.
Interfaces
----------
API endpoints and admin actions delegate to the workflow layer.
They contain no business logic and no shortcuts.
Concurrency
-----------
The system must remain correct under concurrent requests.
Design, not caller discipline, prevents impossible states.
Testing
-------
Tests demonstrate:
- why permissions alone are insufficient
- how policies prevent invalid actions
- how invariants protect system truth
- what happens under race conditions
Clarity matters more than coverage.
Structure
---------
Policies, invariants, and workflows each live in clearly named locations.
Naming favors clarity over cleverness.
Documentation
-------------
The README explains:
- the intent of the project
- how it maps to the series
- how a request flows through the system
It should read like an architectural walkthrough.
Non-Goals
---------
This project does not aim to be:
- a full CMS
- a Django tutorial
- a security framework
- a feature-rich application
End State
---------
After reading the series and exploring this project, a reader should clearly see:
- why authorization is not one check
- why boundaries matter
- how systems fail when those boundaries collapse
